In a recently Maven 2 project migrated to Maven 3, I have warnings (scope must be one of [provided, compile, runtime, test, system] but is '...') due to use of custom scopes.
The custom scope in question is package and I could not find documentation/hint about which is the default when encountering invalid/custom scope.
Does the "package" custom scope ring anything to those still knowing maven 2? I could find references here and here but that's almost all.
What is the default scope in that case? (I guess it is compile, but I'd like to be sure before changing anything).
Regards,
I wasn't aware that a scope package existed. The blogs entries are simply wrong. The default scope is compile and you can find the documentation about the available scopes.
If you have a default like the scope you simply omit the entry from your dependency.
Older versions of Maven like 2.0.11, 2.2.1 do not check all entries in the pom file like the scope so it has been ignored since Maven 3 they are checked for valid values.
Related
package com.yada.yada
What happens with IntelliJ when I create Java class 'ss' in com.yada.yada without package statement? - RED "Missing Package Statement".
What happens when I create Kotlin file in com.yada.yada without package statement? - "Keep going bro until your DI framework will fail to scan your deps during runtime"
Why IJ package validation is non-mandatory for Kotlin? I just wasted an hour trying to figure out what's wrong with package scan only to realise this was the show stopper. Would Java 9 jigsaw quadruple the chaos for Kotlin sparked by such malformed files/classes with no warning messages? Well, you bet it will!
Please return back the "warning" statement for Kotlin. P.S. registration/login methods are not sufficient for myself to access Intellij bugtracker(and I am genuinely pissed off with one time access password resets, 1000 resources and 980 passwords I don't remember or care to) therefore making this public on stackoverflow.
If anybody going to defend this behaviour please explain why? Maybe I am missing something, otherwise please reply with open bug(preferably somebody from JetBrains) and I will accept it.
The missing inspection warning for files with no package statement is a bug; the corresponding YouTrack issue is here.
I'm not sure this post is appropriate here, but to answer the actual question, the official documentation states that:
If the package is not specified, the contents of such a file belong to
"default" package that has no name.
Since with Kotlin your files don't have to be in folders that match their packages, not having a package declaration has to be an option so that you can have files that are organized in folders, but you don't wish to put them in packages - this way they can have the same package as if they weren't nested in any folders, and were just in the root of the project.
I do concede that it's a bit odd there is a warning for your package declaration not matching the folder your file is in, but you don't get this if you just omit the package declaration altogether. I suppose this is assumed to be intentional.
This shouldn't generally be a problem because IDEs will generate the appropriate package declaration for the folder you've created your file in by default. I'm not sure how you created a file without a package declaration if you're using IntelliJ, unless you did it in the root src folder instead of inside a package folder.
I'm slowly beginning to understand the importance of module configurations within the Ivy universe. However it is still difficult for me to clearly see how the same chunk of code could have different configurations that have different dependency requirements (the one exception is in the case of test configs that require JUnit on top of the normal dependencies -- I actually understand that 100%!)
For instance, take the following code:
package org.myorg.myprogram.core;
// Import an object from a dependency
import org.someElse.theirJAR.Widget;
public class MyCode
{
public MyCode()
{
if(Widget.SOME_STATIC == 3)
System.out.println("Fizz");
else
System.out.println("Buzz");
}
}
Now aside from the fact that this is terrible code, I just don't see how my program (which, let's pretend is JARred up into MyProgram.jar) could be set to have multiple "configurations"; some of which may require theirJAR and its Widget class, and others that don't. To me, if we fail to provide MyCode with a Widget it will die at runtime, always.
Again, I understand the necessity for test configurations; just not anything else (I have also asked questions about compile- vs run-time dependencies, and I guess I also see the necessity for those as well). But beyond test configs, compile-time configs, and runtime configs, what other module configurations could you possibly need? How would MyCode need a Widget in some cases, and not in other cases, yet still run perfectly fine without a Widget?
I greatly appreciate any help wrapping my brain around this!
Hibernate is a good example. Hibernate supports multiple cache implementations to act as its level-2 cache. You don't want to transitively depend on all the possible caches, only the one you use.
In general, we use the typical compile, test, runtime set of configurations.
To add to SteveD's answer, remember that dependencies can be more than just .jar files. Some dependencies come with source and javadoc files, release notes, license files, etc. Multiple configurations of the dependency might let you select the subset of files you wish to resolve.
You might also want to use configurations to control the contents of different distributions. For example you might want to release the jar on it's own ("master" configuration in Maven parlance) and additionally build a tar package containing all runtime dependencies, with (or without) source code.
Another use for configurations is when you target multiple platforms. I often release groovy scripts packaged to run as standalone jars or as tomcat web applications
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
The Maven POM schema is version 4.0.0.
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
In a POM-file i found a "maven-ear-plugin" configuration that uses "defaultJavaBundleDir", but it seems that "defaultLibBundleDir" is the correct (according to the schema and various documentation).
Actually, the configuration element of a plugin can contain anything. So <foo>bar</foo> is valid (and will just be "ignored" by a given plugin if it's an unknown parameter).
Is this a remnant from an older version? I couldn't find an explanation for this change, and would like to make sure we are using the correct notation reliably.
This change has been introduced for the resolution of MEAR-46 as we can read in the (approximative) comment of the svn commit: r471886.
Added defaultLibDir as an alias of defaultJavaBundleDir which is more understable
If you look closer at the diff, you'll see that defaultLibBundleDir is the new name of the parameter and that the old defaultJavaBundleDir is declared as an alias.
So both work, both do the same thing, but only the "new" one is documented in the parameters list of the ear mojo. You can safely change to defaultLibBundleDir and this will make things more clear.
Also worth noting is that the Maven Integration for WTP eclipse plugin (m2e-wtp) only supports the documented defaultLibBundleDir option, not the older defaultJavaBundleDir.
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultLibBundleDir
https://github.com/eclipse/m2e.wtp/search?utf8=%E2%9C%93&q=defaultJavaBundleDir
In my project, there are 2 libraries, each of which depend on the XML parsing class java.xml.parsers.DocumentBuilderFactory. Each of these libraries reference the file from different jar (one gets it from a jar called xmlParserAPIs while another gets it from xml-apis-1.0.b2.jar). Unfortunately there are different versions of the class in each of these files so I am seeing runtime errors, depending on the order they are loaded. Both of these xml jars are transitive dependencies of 3rd party libraries. Is there a good way to handle this conflict?
edit: I'm not sure if it makes a difference on how to handle the problem but this only happens in testing because one of the dependencies is in the test scope.
thanks,
jeff
(...) Unfortunately there are different versions of the class in each of these files so I am seeing runtime errors, depending on the order they are loaded.
In theory, xml-apis.jar and xmlParserAPIs.jar (from xerces2-j) are the same JARs but with different names, xmlParserAPIs.jar being deprecated for years (see this message and this one).
If your dependencies relies on different and incompatible versions of xml-apis.jar, I would say that these dependencies are mutually exclusive, in other words incompatible, at least for the versions you're using. The only solution would be to find versions with a converging dependency.
In case they could use compatible versions, use a dependency exclusion for xmlParserAPIs.jar to use xml-api.jar only.
I'm not sure if it makes a difference on how to handle the problem but this only happens in testing because one of the dependencies is in the test scope.
No, this just explains why you don't get the problem at runtime (because the test scoped is not on the classpath then and, obviously, doesn't conflict).
I'm creating some Maven artifacts for various dependencies for our projects, and while I'm taking my best guess at group / artifact IDs, I'd like to add something to flag them as "unofficial" and created by us for compilation, so that should we find official sources for the same thing in the future there's no confusion and we can simply change to point to the identifiers. Is there a best/common/reccomended practice for doing so?
I was just thinking something like setting groupId="org.providername.unofficial", but since Maven's all about "doing it our way" I just want to see if there's a precedent for something different already...
Maven coordinates to uniquely identify any artifact include groupId, artifactId and version. So, changing any of those would allow you to differentiate your artifact from other one. However if you want to be able to use your version instead of a standard artifact as one of the dependencies of some other component you would have to keep the same groupId and artifactId, or else you'd have to deal with excludes in that dependency. So, for that is would be the best to change just version, e.g. add some qualifier like 1.0mycompayname.
Is there a best/common/recommended practice for doing so?
To my knowledge, there is no official recommended practice for this (since the artifacts are non public after all) but I find that using a flag is a good idea that we also use (with an "internal" qualifier) and we also put such artifacts in a special "third-party" group of our repository manager.