|
There are several steps involved in actually coding a plugin. We're not going to discuss the details of what you need to do on this page, we'll leave that for the product specific plugin guides. But we will outline here how you need will work and test your plugin efficiently. In order to test your plugin, you need to deploy it into a running instance of the product. While you could start and stop the server manually and reinstall in the latest version of your plugin after each code-change, you can also use Maven to automate a lot of tasks: A simple Maven task can set up and start an application server, a simple database with some basic settings, and enable you to tear the application down easily too. You can even drop the complete setup by just removing one directory and start all over again, at no extra configuration cost. Basically, what you do is run the command > mvn -Pplugin-debug This creates a "plugin-debug" folder, starts up Tomcat, puts all the logfiles into the appropriate subdirectories, and enables you to use the product straight away: Once you see a note on the commandline interface telling you that you can stop the server using CTRL-C, you will know it is up and running and accepting browsers to connect to it. There are some subtle differences in how this works for Confluence and the other products: JIRA, Bamboo and other productsPlugins in JIRA are not dynamically loadable. They must be installed in JIRA's WEB-INF/lib and the application restarted. The Atlassian Plugin Maven Archetypes come with a profile called plugin-debug. Running the command > mvn -Pplugin-debug will compile your plugin's classes, create a jar in the /target directory, copy that jar into JIRA's WEB-INF/lib directory and restart JIRA. The process will continue running in the foreground, so when you're ready to stop or restart JIRA, you just need to hit CTRL-C to quit. Maven will also install some default data into this instance: things like a license, database configuration, and an admin account. This will save you the effort of having to set up JIRA each time. It's important to note that the license installed is a unique one: it is perpetually valid, but only for a period of three hours (which should be more than enough time to run your tests.) Should you keep going longer than three hours, JIRA will lock you out, and you'll need to restart it to proceed. JIRA will be running at http://localhost:1990/jira, so you can go directly there in your browser and see your latest changes. You'll be able to log in with the username admin and the password admin. As you make changes, you'll have to kill the JIRA process (ctrl-c) and the run mvn -Pplugin-debug again. ConfluenceConfluence works very similarly, but it has the advantage that plugins are dynamically reloadable. So we take advantage of this to speed the development process. When you run > mvn -Pplugin-debug in a Confluence plugin we follow the same steps at first: mvn compiles the plugin, creates a jar, and starts Confluence. As with JIRA, the process will continue running in the foreground, so you just need to hit CTRL-C to quit. Maven will also install some default data into this instance: things like a license, database configuration, and an admin account. This will save you the effort of having to set up Confluence each time. It's important to note that the license installed is a unique one: it is perpetually valid, but only for a period of three hours (which should be more than enough time to run your tests.) Should you keep going longer than three hours, Confluence will lock you out, and you'll need to restart it to proceed. However, rather than copying the JAR to WEB-INF/lib then in uses the Atlassian Maven PDK to dynamically deploy the plugin. From there, you can run the PDK goals like uninstall and install to deploy your changes without having to wait for Confluence to restart. You'll want to keep another terminal window open so that you can run these commands while the Tomcat process is running in the other window. Confluence will also be running at http://localhost:1990/confluence, so you can go directly there in your browser and see your latest changes. You'll be able to log in with the username admin and the password admin. As you make changes to your code, you can redploy your plugin by using the Atlassian Maven PDK and running > mvn atlassian-pdk:install The main logfile you will be interested in is located in "target" and called "output.log".
Debugging your pluginWhen you run JIRA or Confluence with the plugin-debug profile, they are automatically configured to accept a remote debugger - in this case IDEA or Eclipse. We've also made sure to include source-code artifacts for most of the important code in the products: both the core applications and key libraries like atlassian-plugins or atlassian-renderer. Maven attaches those source code artifacts to your plugin automatically, so you can pull up most classes and read the code or insert breakpoints as needed. You'll want to create a remote debug target in your IDE. But once you've done that, you can start the debugger to JIRA or Confluence and step through the code in your plugin, or in the product itself. (You will not need to explicitly use VM parameters when running your plugin, as Intellij indicates when you are creating a remote debug target, because the parameters have already been set up for you.) Please see also the Ports used by applications section in the remote target creation page. |
Labels
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.
Comments (28)
Mar 20, 2008
Wim Deblauwe says:
I don't understand at what time you need to run mvn atlassian-pdk:install if you...I don't understand at what time you need to run mvn atlassian-pdk:install if you are developing a JIRA plugin? Since running mvn -Pplugin-debug redeploys the plugin itself, what is the use? Or have I understood something incorrectly?
Mar 20, 2008
David Peterson [CustomWare] says:
I think you'll find that the 'plugin-deploy' profile automatically uses the atla...I think you'll find that the 'plugin-deploy' profile automatically uses the atlassian-pdk:install goal internally. So you may not have to use it directly yourself at all. I use it all the time for Confluence because you can hot-swap a new version of the plugin into Confluence without restarting the server. Not really applicable with JIRA yet unfortunately.
Apr 21, 2008
Nanda Firdausi says:
I encounter this error when trying to run the plugin-debug target: Embedded err...I encounter this error when trying to run the plugin-debug target:
Embedded error: Replace: source file /Users/nanda/Documents/workspace/OfflineAccess/plugin-debug/confluence-home/confluence.cfg.xml doesn't exist
Can somebody help me?
May 21, 2008
Jitendra says:
I got the following error when I run command 'mvn -Pplugin-debug' 2008-05-2...I got the following error when I run command 'mvn -Pplugin-debug'
2008-05-21 11:58:11,796 INFO [main] [com.atlassian.confluence.lifecycle] contextInitialized Starting Confluence 2.8.0 (build #1318)
2008-05-21 11:59:04,015 ERROR [main] [com.atlassian.upgrade.AbstractUpgradeManager] doUpgrade Upgrade failed: null
java.lang.NullPointerException
at org.apache.commons.codec.digest.DigestUtils.md5(DigestUtils.java:86)
at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.getAliasForSid(DefaultTrustedApplicationsManager.java:179)
at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.getSystemAlias(DefaultTrustedApplicationsManager.java:173)
at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.getCurrentApplicationInternal(DefaultTrustedApplicationsManager.java:153)
at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.getCurrentApplication(DefaultTrustedApplicationsManager.java:109)
at com.atlassian.confluence.security.trust.DefaultTrustedApplicationsManager.initConfluenceKey(DefaultTrustedApplicationsManager.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
.
.
.
.
.2008-05-21 11:59:04,296 FATAL [main] [com.atlassian.upgrade.UpgradeLauncherServletContextListener] contextInitialized Upgrade failed, application will not start: java.lang.NullPointerException
com.atlassian.upgrade.UpgradeException: java.lang.NullPointerException
at com.atlassian.upgrade.AbstractUpgradeManager.doUpgrade(AbstractUpgradeManager.java:135)
at com.atlassian.upgrade.AbstractUpgradeManager.upgrade(AbstractUpgradeManager.java:52)
at com.atlassian.confluence.upgrade.impl.DefaultUpgradeManager.upgrade(DefaultUpgradeManager.java:72)
at com.atlassian.upgrade.UpgradeLauncherServletContextListener.contextInitialized(UpgradeLauncherServletContextListener.java:26)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3763)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4211)
.
.
Can anybody help me please?
Oct 07, 2008
Sean Dockery says:
I am just learning how to develop a Bamboo plug-in. Because I am new to this pr...I am just learning how to develop a Bamboo plug-in. Because I am new to this process, it is not always obvious to me what is applicable and what is not, so please be patient with me if I am off course in my efforts.
I have been attempting to execute the mvn -Pplugin-debug command for my plug-in. The command fails as Maven is complaining that it is unable to download JavaMail 1.3.2 from the Atlassian repository. But it also gives instructions to go to the JavaMail page on Sun's web site, download JavaMail 1.3.2, and install it into the repository cache manually. Here is the message from Maven:
I tried the Sun web site, but I am unable to locate a "previous downloads" area for JavaMail and have, therefore, be unable to obtain a copy of JavaMail 1.3.2. Will this problem be fixed with the Atlassian repository? Is there something else I can do to properly resolve the dependency. (Please bear with me as I am relatively unfamiliar with configuring Maven.)
Thanks.
Oct 07, 2008
Sean Dockery says:
I have posted this same message in the Bamboo Development forum: http://forums....I have posted this same message in the Bamboo Development forum:
http://forums.atlassian.com/thread.jspa?threadID=29148&tstart=0
Oct 22, 2008
J. Longman says:
Slightly lower in the page is the list of earlier releases and you want http://...Slightly lower in the page is the list of earlier releases and you want
http://java.sun.com/products/javamail/javamail-1_3_2.html
Oct 26, 2008
Tibor Hegyi says:
Hi, I also get this with Confluence. I'm developing a plugin, the recommended wa...Hi, I also get this with Confluence.
I'm developing a plugin, the recommended way of deploying plugin dynamically to confluence running at http://localhost:1990/confluence is calling mvn atlassian-pdk:install.
When I do this, I get the below error:
[INFO] Uninstall Plugin: Method failed: HTTP/1.1 400 No Host matches server name localhost [INFO] ------------------------------------------------------------------------ [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Uninstall Plugin: Method failed: HTTP/1.1 400 No Host matches server name localhost at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:903) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Uninstall Plugin: Method failed: HTTP/1.1 400 No Host matches server name localhost at com.atlassian.maven.plugins.pdk.BasePluginServerMojo.execute(BasePluginServerMojo.java:117) at com.atlassian.maven.plugins.pdk.UninstallPluginMojo.execute(UninstallPluginMojo.java:82) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 19 moreAny idea on how to fix this?
Thank you,
Tibor
Oct 26, 2008
Tibor Hegyi says:
I got it. I have tried to override the settings.xml specifying -Datlassian.pdk....I got it.
I have tried to override the settings.xml specifying -Datlassian.pdk.server.username=admin -Datlassian.pdk.server.password=admin -Datlassian.pdk.server.url=http://localhost:1990/confluence, but it did not seem to take effect, as the PDK tool was still using the pdk server url from settings.xml.
I had to change settings.xml and specify the correct PDK server url for confluence:
This worked.
Cheers,
Tibor
Oct 31, 2008
Sean Wolfe says:
Hi, I'm wondering if there is an easy way to configure or setup the default conf...Hi, I'm wondering if there is an easy way to configure or setup the default configuration in server.xml for the Tomcat instance that mvn -Pplugin-debug creates for Jira. After some frustrating debug cycles, I realized that this command unpacks a fresh new copy of tomcat each time it's ran, so I am unable to make changes, install the plugin, quickly stop/start the service, and keep my configuration without doing the whole build process manually. This doesn't make sense since this is the reason for using Maven.
I tried searching through all the Poms and other code in the repository, but I can't seem to easily find the one point where Tomcat loads the configuration. I see where the config is being set, but I don't understand how to get those settings in there.
The reason I need to do this is because I'm testing a plugin that heavily relies on CAS authentication, and CAS won't work without SSL.
Oct 31, 2008
Tim Moore says:
Sean, It grabs Tomcat from the URL defined by the tomcat.installer.url property...Sean,
It grabs Tomcat from the URL defined by the tomcat.installer.url property. I think your best bet would be to create a custom Tomcat distribution zip with exactly the configuration you need, put that on an internal web server somewhere, then override tomcat.installer.url in your plugin's pom.xml to point there.
By the way, if you didn't already know about it, http://forums.atlassian.com has a JIRA Development forum that is better for these types of questions because a lot more people watch that than this page.
Good luck!
Oct 31, 2008
Sean Wolfe says:
Hi, Thanks for your reply. I tried what you described here. I created a custom ...Hi, Thanks for your reply.
I tried what you described here. I created a custom tomcat ZIP archive, and placed it on a webserver. I then configured my pom.xml file to have the <tomcat.installer.url> set to the archives path in the project/properties section.
But my installation still gets overwritten every time I run mvn -Pplugin-debug.
Should I just set unpack.jira.config.overwrite to false?
I'll take a look at the Jira Forums.
Thanks
Nov 25, 2008
Matthew Langley says:
I'm trying to set up the environement to dev a Jira plugin on Windows Vista... ...I'm trying to set up the environement to dev a Jira plugin on Windows Vista... I have gotten everything to work, except when I get to trying to run my newly created plug with the debug command, it gets (seemingly) quite a bit of the ways and then spits this error about running Tomcat:
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to create a Tomcat 5.5.23 standalone configuration
Malformed \uxxxx encoding.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.codehaus.cargo.container.ContainerException: Failed to create a Tomcat 5.5.23 standalone configuration
at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration.configure(AbstractLocalConfiguration.java:165)
at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:144)
at com.atlassian.maven.plugins.testharness.AbstractStartCargoServiceMojo.startContainer(AbstractStartCargoServiceMojo.java:194)
at com.atlassian.maven.plugins.testharness.AbstractStartServiceMojo.execute(AbstractStartServiceMojo.java:147)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
at java.util.Properties.loadConvert(Properties.java:492)
at java.util.Properties.load(Properties.java:331)
at org.codehaus.cargo.container.internal.util.PropertyUtils.getDataSourceProperties(PropertyUtils.java:65)
at org.codehaus.cargo.container.property.DataSource.(DataSource.java:96)
at org.codehaus.cargo.container.tomcat.Tomcat5xStandaloneLocalConfiguration.createDatasourceTokenValue(Tomcat5xStandaloneLocalConfiguration.ja
va:101)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.createContextToken(AbstractCatalinaStandaloneLoca
lConfiguration.java:250)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.createTomcatFilterChain(AbstractCatalinaStandalon
eLocalConfiguration.java:214)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.doConfigure(AbstractCatalinaStandaloneLocalConfig
uration.java:69)
at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration.configure(AbstractLocalConfiguration.java:161)
... 21 more
java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
at java.util.Properties.loadConvert(Properties.java:492)
at java.util.Properties.load(Properties.java:331)
at org.codehaus.cargo.container.internal.util.PropertyUtils.getDataSourceProperties(PropertyUtils.java:65)
at org.codehaus.cargo.container.property.DataSource.(DataSource.java:96)
at org.codehaus.cargo.container.tomcat.Tomcat5xStandaloneLocalConfiguration.createDatasourceTokenValue(Tomcat5xStandaloneLocalConfiguration.ja
va:101)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.createContextToken(AbstractCatalinaStandaloneLoca
lConfiguration.java:250)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.createTomcatFilterChain(AbstractCatalinaStandalon
eLocalConfiguration.java:214)
at org.codehaus.cargo.container.tomcat.internal.AbstractCatalinaStandaloneLocalConfiguration.doConfigure(AbstractCatalinaStandaloneLocalConfig
uration.java:69)
at org.codehaus.cargo.container.spi.configuration.AbstractLocalConfiguration.configure(AbstractLocalConfiguration.java:161)
at org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:144)
at com.atlassian.maven.plugins.testharness.AbstractStartCargoServiceMojo.startContainer(AbstractStartCargoServiceMojo.java:194)
at com.atlassian.maven.plugins.testharness.AbstractStartServiceMojo.execute(AbstractStartServiceMojo.java:147)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
I realize the uxxxx error most likely means a backslash is being put in an incorrect location, though I cannot figure out where, any ideas?
Dec 02, 2008
Jonathan Nolen says:
Try looking through your pom.xml for anything with \u.... Probably the tomcat in...Try looking through your pom.xml for anything with \u.... Probably the tomcat installer location?
Dec 04, 2008
Carlos Alvarez says:
I had the same problem using windows platforms. The best solution I could achiev...I had the same problem using windows platforms. The best solution I could achieve was to use linux instead
Seriously, is a trouble with the datasource value for the hsqldb. Cargo uses the property cargo.datasource.datasource for the hsql datasource.
The problem start with this https://maven.atlassian.com/repository/public/com/atlassian/jira/plugins/jira-plugin-base/8/jira-plugin-base-8.pom . As you can see, the value for the cargo.datasource.datasource is jdbc:hsqldb:${atlassian.product.config.directory}/jira-home/database.
The trouble is the ${atlassian.product.config.directory } . In windows, the value for that variable is something like "\programas\atlassian\jira". When cargo builds the datasource with this inverted backslahs, it is interpreted as full of escape characters, so you have your bad encoding: \something.
Two solutions:
1. Download that pom in the repository and change the value of the cargo.datasource.datasource.
2. Change the cargo to encode the datasource property (class org.codehaus.cargo.container.tomcat.Tomcat5xStandaloneLocalConfiguration, method createDatasourceTokenValue())
Take a look at http://jira.codehaus.org/browse/CARGO-603
Dec 04, 2008
Matthew Langley says:
Thanks for the response... ouch. What sort of mvn command would allo...Thanks for the response... ouch. What sort of mvn command would allow me to grab that .pom file?
Dec 05, 2008
Carlos Alvarez says:
I don't know how to grab only that pom. Actually, what I did was to inspect the ...I don't know how to grab only that pom. Actually, what I did was to inspect the efective pom (the pom after the resolution of the inheritance dependencies) and edit it locally, to let it become my new pom.
Just in case, the command to get the effective pom is
mvn help:effective-pom
HTH
Dec 08, 2008
Matthew Langley says:
Thanks a lot for the help. Have never used Maven so this is a new workflow...Thanks a lot for the help. Have never used Maven so this is a new workflow for me. Where do I put the outputed and modified .pom to ensure it gets compiled with the changes I made?
Dec 08, 2008
Tim Moore says:
How annoying! Someone else reported the problem as http://jira.codehaus.org/...How annoying! Someone else reported the problem as http://jira.codehaus.org/browse/CARGO-568
However, I don't recommend editing jira-plugin-base-8.pom directly. For one thing, your plugin build won't be very repeatable. Anyone else trying to build your plugin on Windows would need to make the same change. Secondly, if you ever update your base POM version, you'd have to make the change again (and we recommend keeping up-to-date with new base POMs as we release them, as they may contain important bug fixes). Similarly, using the output from "help:effective-pom" isn't ideal, because then you can't really update to a new base POM at all.
Instead, it's usually possible in Maven to override configuration from an ancestor pom in a descendant pom. In this case, it requires quite a bit of boilerplate, but if you put the following into your plugin's own POM you should be set:
I'll try to figure out the best way to work around this problem in the base POM.
P.S. You might want to consider posting questions like this on the appropriate development forum at http://forums.atlassian.com. Those are checked more frequently, by more people, than the comments in this space.
Dec 23, 2008
Matthew Langley says:
Thanks for the post. I tried adding that to my pom.xml (I'm guessing that'...Thanks for the post. I tried adding that to my pom.xml (I'm guessing that's where I add it?) and still a no go. Thanks for the forum link, searching there now to see if my problem has come up already and if not I will post there too.
Jun 08
Ben Kearney says:
If anyone else is still having trouble with this problem, I hope the fix that wo...If anyone else is still having trouble with this problem, I hope the fix that worked for me can help someone else.
I could not get the workaround above to work for me. But I managed to fix it with another approach, which I described in http://forums.atlassian.com/message.jspa?messageID=257308566#257308566.
Basically, I called atlassian-test-harness in my POM and forced it to use cargo-maven2-plugin v1.0.
Cheers!
-Ben
<build> <plugins> <plugin> <groupId>com.atlassian.maven.plugins.testharness</groupId> <artifactId>atlassian-test-harness</artifactId> <dependencies> <dependency> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>1.0</version> </dependency> </dependencies> </plugin> </plugins> </build>Dec 30, 2008
Ram Tandukar says:
Just thought that I would add that I was able to resolve the 'Malformed \uxxxx e...Just thought that I would add that I was able to resolve the 'Malformed \uxxxx encoding.' issue by mapping a drive to my project directory so that it excludes any \u or other escape characters in the datasource path. I can then run 'mvn -Pplugin-debug' from the new drive ok.
Feb 13
Matthew Langley says:
This worked perfectly for me, thanks for sharing. What I did run into though, o...This worked perfectly for me, thanks for sharing.
What I did run into though, once it was running and I loaded the localhost address in my browser, it brought me to a Jira setup page where it wanted me to insert a license. Now my company has a license, though I was wondering if that is needed to develop a jira plugin (not run another jira server permantently or anything)? I see the text above that says it gives it a "perpetual" license for 3 hours, that doesn't seem to match the setup page I saw, what am I missing?
Feb 13
Cheryl Jerozal says:
hi matthew~ i believe the license should be set up as part of this process. but...hi matthew~
i believe the license should be set up as part of this process. but as a workaround, we do offer free development licenses to customers. the technical contacts on your account should be able to generate them when logged in to http://my.atlassian.com/
~cheryl
Feb 13
Florian Wüchner says:
Hi, i have the same name mangling problem for the datasource-url as desribe in ...Hi,
i have the same name mangling problem for the datasource-url as desribe in the previous posts.
However none of the describe workaround work for me
Has anybody found an other workaround for this problem?
Thanks and cheers,
Florian
P.S.: I have posted the problem in the development forum: http://forums.atlassian.com/thread.jspa?threadID=31973
May 11
Nick Fishwick says:
Hi, Has anyone run into this problem... When I recompile using mvn atlassian-pd...Hi,
Has anyone run into this problem...
When I recompile using mvn atlassian-pdk:install (for a Confluence plugin), I always get the following error in the Confluence Plugin Manager:
Error: There was a problem loading the descriptor for module 'macro' in plugin 'PM-Toolkit'. Class version is incompatible with current JVM: com.fishbytes.confluence.plugins.pmtoolkit.pmtk_dash_tabbed
BUT if I delete the Target folder and recompile from scratch the plugin builds and installs just fine.
Any hints would be much appreciated.
Thanks
Nick
May 12
Tim Moore says:
That error indicates that you compiled your classes with a version of the JDK th...That error indicates that you compiled your classes with a version of the JDK that is newer than what you're running with. Often that's because your IDE is using one version while your command-line PATH has an older one. Then, if you clean and rebuild from the command line, you're using the older one so it works. IntelliJ IDEA, in particular, has a bad habit of ignoring the jdkLevel property in your POM and using whatever JDK version it was run with by default until you configure another one in your project settings.
May 13
Nick Fishwick says:
Thanks Tim,. that makes a lot of sense. Nick...Thanks Tim,. that makes a lot of sense. Nick...