[mojo-dev] [jira] (MAPPASM-213) Allow generation of logs directory and temp directory when creating a jsw wrapper.
Title: Message Title Dennis Lundberg updated an issue Mojo's AppAssembler Maven Plugin / MAPPASM-213 Allow generation of logs directory and temp directory when creating a jsw wrapper. I think this is a reasonable request, and the implementation is not invasive for users who do not use the new configuration parameters. I can also see use cases for a feature like this when using the assemble goal. I'll have a look and see if I can make that work. Change By: Dennis Lundberg Fix Version/s: 1.8 Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MAPPASM-224) Make Plugin Java 5 Ready
Title: Message Title Dennis Lundberg commented on an issue Re: Make Plugin Java 5 Ready First patch applied in r19570. It fixes: Update to latest parent Use Java 5 plugin annotations Change some code to use generics It would be great if someone could have a look at the applied patch, to make sure I got all the parameter settings correct. It's sometimes tricky to know if an @_expression_ should become a "property" or a "defaultValue"... Still left to do: Go through the code and make use of Java 5 features like generics Add Comment Mojo's AppAssembler Maven Plugin / MAPPASM-224 Make Plugin Java 5 Ready Use Java 1.5 annotations for plugin etc. and upgrade code accordingly. This message was sent by Atlassian JIR
[mojo-dev] [jira] (MAPPASM-224) Make Plugin Java 5 Ready
Title: Message Title
Robert Scholte commented on an issue
Re: Make Plugin Java 5 Ready
I did notice some properties which should actually be defaultValue Difference is now easier to understand: if a property must be able to be set as -Dkey=value, then use property="${key}", otherwise use defaultValue="${key}". If it is readonly, you're almost certain you should use defaultValue
Add Comment
Mojo's AppAssembler Maven Plugin / MAPPASM-224
Make Plugin Java 5 Ready
Use Java 1.5 annotations for plugin etc. and upgrade code accordingly.
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MAPPASM-224) Make Plugin Java 5 Ready
Title: Message Title
Robert Scholte edited a comment on an issue
Re: Make Plugin Java 5 Ready
I did notice some properties which should actually be defaultValue ;)Difference is now easier to understand: if a property must be able to be set as {{-Dkey=value}}, then use {{property=" $\{ key } "}}, otherwise use {{defaultValue="$\{key}"}}.If it is readonly, you're almost certain you should use {{defaultValue}}
Add Comment
Mojo's AppAssembler Maven Plugin / MAPPASM-224
Make Plugin Java 5 Ready
Use Java 1.5 annotations for plugin etc. and upgrade code accordingly.
This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MFINDBUGS-188) Detectors for JCIP/JSR305 concurrency annotations not running
Title: Message Title Kasra F commented on an issue Re: Detectors for JCIP/JSR305 concurrency annotations not running This is even more broken now. I suspect this is a Java 8 issue. I'm not sure if findbugs has Java 8 support. >>> findbugs-maven-plugin:2.5.4-SNAPSHOT:check (default) @ findbugs-maven-annotations-test >>> --- findbugs-maven-plugin:2.5.4-SNAPSHOT:findbugs (findbugs) @ findbugs-maven-annotations-test --- Fork Value is true [java] The following errors occurred during analysis: [java] Unable to get XClass for java/lang/StringBuilder [java] java.lang.ArrayIndexOutOfBoundsException: 26721 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(Subtypes2.java:275) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addClass(Subtypes2.java:244) [java] At edu.umd.cs.findbugs.ba.AnalysisContext.setAppClassList(AnalysisContext.java:941) [java] At edu.umd.cs.findbugs.FindBugs2.setAppClassList(FindBugs2.java:997) [java] At edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:225) [java] At edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:393) [java] At edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1317) [java] Unable to get XClass for java/lang/Class [java] java.lang.ArrayIndexOutOfBoundsException: 2560 [java] At org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.asm.FBClassReader.accept(FBClassReader.java:44) [java] At org.objectweb.asm.ClassReader.accept(Unknown Source) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:110) [java] At edu.umd.cs.findbugs.classfile.engine.ClassParserUsingASM.parse(ClassParserUsingASM.java:587) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:76) [java] At edu.umd.cs.findbugs.classfile.engine.ClassInfoAnalysisEngine.analyze(ClassInfoAnalysisEngine.java:38) [java] At edu.umd.cs.findbugs.classfile.impl.AnalysisCache.getClassAnalysis(AnalysisCache.java:268) [java] At edu.umd.cs.findbugs.ba.XFactory.getXClass(XFactory.java:652) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addInheritanceEdge(Subtypes2.java:1260) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addSupertypeEdges(Subtypes2.java:1233) [java] At edu.umd.cs.findbugs.ba.ch.Subtypes2.addClassAndGetClassVertex(
[mojo-dev] [jira] (MFINDBUGS-188) Detectors for JCIP/JSR305 concurrency annotations not running
Title: Message Title Kasra F commented on an issue Re: Detectors for JCIP/JSR305 concurrency annotations not running It looks like this works after switching to JDK7. BugInstance size is 2 Error size is 0 Total bugs: 2 ImmutableClassTest.x should be final since com.offbynull.peernetic.findbugs.maven.annotations.test.ImmutableClassTest is marked as Immutable. ["com.offbynull.peernetic.findbugs.maven.annotations.test.ImmutableClassTest"] At ImmutableClassTest.java:[lines 6-24] ImmutableClassTest.y should be final since com.offbynull.peernetic.findbugs.maven.annotations.test.ImmutableClassTest is marked as Immutable. ["com.offbynull.peernetic.findbugs.maven.annotations.test.ImmutableClassTest"] At ImmutableClassTest.java:[lines 6-24] Add Comment Mojo's FindBugs Maven Plugin / MFINDBUGS-188 Detectors for JCIP/JSR305 concurrency annotations not running For whatever reason, the detectors that detect concurrency problems through the use of JCIP/JSR305 concurrency annotations don't work when using the maven plugin. Even when including the detectors (FindInconsistentSync2,CheckImmutableAnnotation) explicitly in the plugin configuration, they don't seem to work. I've also tried changing effort and threshold ... This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c)
[mojo-dev] [jira] (MAPPASM-224) Make Plugin Java 5 Ready
Title: Message Title Dennis Lundberg commented on an issue Re: Make Plugin Java 5 Ready Changed the rest of the code to use generics in r19573. Please review the changes. There are still some things left to "generify", but that can't be done right now because of a bug in Modello, see MODELLO-287. Add Comment Mojo's AppAssembler Maven Plugin / MAPPASM-224 Make Plugin Java 5 Ready Use Java 1.5 annotations for plugin etc. and upgrade code accordingly. This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MAPPASM-226) Add ability to rename the executable's prefix( ie wrapper)
Title: Message Title Dan Tran updated an issue Mojo's AppAssembler Maven Plugin / MAPPASM-226 Add ability to rename the executable's prefix( ie wrapper) Change By: Dan Tran Fix Version/s: 1.8 Add Comment This message was sent by Atlassian JIRA (v6.1.6#6162-sha1:7af547c) - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[mojo-dev] [jira] (MAPPASM-226) Add ability to rename the executable's prefix( ie wrapper)
Title: Message Title Dan Tran created an issue Mojo's AppAssembler Maven Plugin / MAPPASM-226 Add ability to rename the executable's prefix( ie wrapper) Issue Type: Improvement Affects Versions: 1.7 Assignee: Unassigned Created: 22/Mar/14 10:44 PM Environment: unix/windows Priority: Major Reporter: Dan Tran When we have multiple jsw services generated by this plugin, each currently use a same executable name ( ex wrapper-windows-x64.exe etc ). It is impossible to figure which executable belong to which app. To improve this, we will add an option arguments executablePrefix with default set to 'wrapper'. allowing user to change this name at build time Add Comment
