I downloaded the necessary pom.xml and jar files, now I need to organize them so Maven can find them, but I'm not exactly sure of the structure. Here's my guess:
For example, the maven-clean-plugin would sit here:
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.xml
I realize the best way to go about this would be download it on my computer and test it out, but I can't.
Also, would the same rule/methodology described in the path above be the same for any other xml and jar files?
I'm asking this because when I run "mvn clean verify -o" I get the error "The POM for org.apache.maven.plugins:maven-clean-plugin:jar:2.5 is missing, no dependency information available", even tho the POM is located in the path described above.
My solution to the problem above is simple, my solution to getting the build to work, is nearly impossible in my situation.
Change the extension of the xml file from
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.xml
to
~/.m2/repository/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom
Once I did that I realized that each jar depends on other jars, which are described as dependencies in the pom file. And since each jar depends on each jar thereafter, etc., etc., it'd be nearly impossible to get each jar and pom, for me.
One thing I was going to mention is that you can command line push files into the .m2 local cache.
check the documentation here for more information: http://maven.apache.org/plugins/maven-install-plugin/usage.html
Related
I have a project with a GDSL file that describes a DSL delegate like:
def ctx = context pathRegexp: ".*installer\\.groovy", scope: scriptScope()
contributor(ctx) {
delegatesTo(findClass("com.whatever.InstallerBase"))
}
I package this file up in the jar (just in the root of the jar) using maven.
In a separate project I have a maven dependency on my jar artifact containing the gdsl. However, my autocompletion doesn't work. It works fine with the sample scripts in the first project (with the GDSL).
Is there a step that I'm missing in order for the GDSL to be picked up? Do I need to place it in a special folder in the jar?
The problem was indeed what #PeterGromov indicated in the comment on the question:
ensure that the library jar is only attached as classes and not library source as well
both the source and library were configured and thus IDEA doesn't include it. I have opened a youtrack issue to fix this here:
https://youtrack.jetbrains.com/issue/IDEA-137411
I am unable to get the --sourcepath option of groovyc to work at all. Can someone furnish a trivial example of it actually doing anything?
Ultimately I want to use "groovyc" at the command line with a directory a packaged organized tree of mixed groovy and java source. I don't want to reference each source file explicitly. And I don't want to use an ant or maven task either, on grounds of both principle (hey is there a bug here?) and because the production scenario that I might want to tweak the source in has neither but will have groovy. I know I could use unix find but must I resort to that?!
sourcepath isn't used anymore. It's only there for backwards compatibility and will be removed in the future.
The Groovy documentation is currently rewritten, you can find a snapshot including the documentation for groovyc here: https://dl.dropboxusercontent.com/u/20288797/groovy-documentation/index.html#ThegroovycAntTask-groovyc
Working on the new android side of extensions with the changes. I have my separate extension as its own dependency.
In my code I require references to the Extension.Java class as well as the HaxeObject.
These are located in extensions-api, which is it's own separate dependency.
I've tried including these files in my own dependency, this causes top-level exceptions because a number of the Java files were included twice. I've also tried not including the extensions-api, this works to some extent, however If in the future I decide to use more extensions this won't work (less than ideal).
I need to find a way to reference these files from one dependency to another. so from: MyExtension.src.org.haxe.nme.MyExtension and extension-api.src.org.haxe.nme.Extension
So I guess the point I'm stuck at is how I make these two dependencies see each other whilst compiling so that when they merge to make the .dex file they don't cause top-level exceptions.
I could potentially hack it by placing my extension into the extension-api folder. Something like:
<dependency name="extension-api" path="dependencies/MyExtension" if="android"/>
The issue with this being that the androidManifest merging wouldn't work.
I found the answer here:
the gist is in the project.properties file you want to add the line:
android.library.reference.1=../extensions-api
http://www.openfl.org/community/general-discussion/native-extensions/
I have a groovy project in IntelliJ IDEA that uses logback.groovy. It's in src/main/resources so that it ends up in the classpath of the project, but IDEA compiles it into logback.class. Logback expects this to be in .groovy format, so this won't do. Is there a way to prevent this behavior? I just want logback.groovy in my classpath for running unit tests and webapp debugging.
IDEA 13 now supports new types of directory assignments under your content root: the relevant one for this question is "resources".
In previous versions, IDEA only supported marking directories as "sources" or "tests".
So the new correct answer is to mark src/main/resources directory as a resources folder of your content root. By marking the contents of a directory as "resources", you're telling IDEA that the contents are not source code but need to be accessible on the classpath at runtime.
[Added as a separate answer because the first one is still potentially useful if your file is stuck under your source tree for whatever reason - feel free to merge it in to the other answer if that's more appropriate.]
I guess /src/main/resources is marked in IDEA as a source root? That's pretty much explicitly telling IDEA "the stuff under this directory is source files".
You could try adding the file to /Settings/Project Settings/Compiler/Excludes - but that will probably mean that your file won't get copied onto your output path (and thus won't be on the runtime classpath so logback won't see it).
My personal solution is that my logback.groovy sits outside of my /src tree - I consider it to be configuration rather than a source/resource file. My config directory itself is then added to the runtime classpath directly via /Project Structure/Modules//Dependencies (marked as runtime scope).
My solution was to modify the artifact to explicitly include logback.groovy in the WEB-INF/classes directory. It isn't ideal since this file could only be referenced by the absolute path and not as a project file, so any suggestions are still welcome.
I put logback.groovy in src/main/resources and added it to Resources patterns in IDEA's Compiler settings (ctrl + alt + s; Compiler > Resource patterns). And it works :)
I'm working on a Java ME/J2ME project which makes use of the Bouncy Castle J2ME library. When adding it to my project, however, I've noticed the resulting .jar file size increases 40 times (50kB vs. 2000kB). Other than setting ProGuard's obfuscator settings to level 9 (max), is there any other way I can minimize this increase in file size?
I'm only using a few of the libraries actual classes, namely:
import org.bouncycastle.util.encoders.Hex;
import org.bouncycastle.crypto.Digest;
import org.bouncycastle.crypto.macs.HMac;
import org.bouncycastle.crypto.params.*;
import org.bouncycastle.crypto.digests.SHA256Digest;
Thanks in advance.
Now this is a very tricky one!
Before anything else please can you unzip your jar file and see if the Proguard has obfuscated the class files of BouncyCastle? Since you have included bouncycastle jar file as a library and there are class files in it so I am assuming the Proguard hasn't obfuscated these class files which are taking much of the space.
Anyways I have just downloaded the bouncy castle jar file and can see it is purely made up of class files, so there are no extra files which we might be able to delete and get rid of to reduce the resultant jar file.
Now If you really want to reduce then read on I am going to produce two solutions, both of them are risky:
Solution 1 (Not Recommended):
This is easy but I wouldn't recommend, It may cause runtime exceptions or errors:
Unzip the bouncycastle jar file. Then navigate to the directory src\org\bouncycastle
As you have mentioned you are only using these below packages
org.bouncycastle.util.*
org.bouncycastle.crypto.*
Now here I will be assuming that the source code inside these two packages is not dependant on the source code/class files inside other packages.
Now delete the other directories namely "asn1", "bcpg". At this stage I will not become a butcher and delete everything but will go by deleting a couple and then come back and delete others if it worked.
Now we will regenerate the jar file. After you have deleted the directories now go back to the root of the directory where you will see other directories like
META-INF
org
utils
This is an important step you need to this correctly otherwise jar file will not work. Select all the directories in the root directory and
then right click-> send to zip
Once the zip file is created then rename it to having *.jar instead of *.zip
The size of the jar file would have reduced and now include this jar file in your project. See if it compiles and executes. Then check
your functionality if it is working correctly at Runtime. If all goes fine, then you are done.
Now you can repeat from above steps to delete further directories to reduce the jar file size.
Solution 2:
Download the source code of the bouncycastle jar file that you are using.
You will have to remove the jar file from the project.
Include the source code into the project. Build the project and see if you dont get any compilation error. You have to be sure at this stage
that you are not using the original jar file, and only using the code.
Now start deleting the packages containing code that you dont need. Keep rebuilding the project that it doesn't come up compilation error,
and if it does then you dont want to delte that package and move on deleting others.
Once this butchring is done then Build the project and generate the jar file.
By this way the Proguard will obfuscate code of bouncy castle and because of deleting most of the code not needed you should get a substantial
decrease in the resultant jar file.