AW: Problems with MAVEN's-ANT on OpenVMS
Hi Wayne
Thank you Wayne for this excellent Analysis. If a routine belonging to the file
system returns something badly,
there is a little chance to influence by a logical JAVA$FILENAME_CONTROL which
can be set to so many values
used to control filename encodings, particular how to deal with dot's in file
names.
Josef
-Ursprüngliche Nachricht-
Von: Wayne Fay [mailto:wayne...@gmail.com]
Gesendet: Donnerstag, 20. Oktober 2011 23:51
An: Maven Users List
Betreff: Re: Problems with MAVEN's-ANT on OpenVMS
With knowing the details about our environment
would you expect that Lucene written in clean Java
is not operating on such a platform?
Without a comprehensive analysis of the source code for Lucene (and
potentially, some or all of its dependencies) it is impossible to say
anything conclusive about how well it may operate on OpenVMS or any
other operating system except for those explicitly supported (and
tested) by the dev team. Java isn't truly write-once run-anywhere,
despite such claims ~10-15 years back.
I looked at your stacktrace and the problem seemed to be related to a
NumberFormatException thrown by java.lang.Long.parseLong() that is not
being caught and handled by Lucene:
Caused by: java.lang.NumberFormatException: For input string: 1.
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:419)
at
org.apache.lucene.index.SegmentInfos.generationFromSegmentsFileName(SegmentInfos.java:199)
I found a Lucene JIRA issue that is loosely related:
https://issues.apache.org/jira/browse/LUCENE-3008
Looks like line 211 in trunk is the issue (was line 199 in the stacktrace):
http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lucene/index/SegmentInfos.java?view=markup
The source code is:
return Long.parseLong(fileName.substring(1+IndexFileNames.SEGMENTS.length()),
Character.MAX_RADIX);
A quick look at the Java API shows:
http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Long.html#parseLong(java.lang.String,%20int)
An exception of type NumberFormatException is thrown if any of the
following situations occurs:
* Any character of the string is not a digit of the specified
radix, except that the first character may be a minus sign '-'
('\u002d') provided that the string is longer than length 1.
The decimal character in the string 1. is not valid in the radix
defined by Character.MAX_RADIX. So, you'll need to figure out where
that filename of 1. is coming from -- either OpenVMS or Lucene --
and somehow get rid of the decimal in the filename. Or just rename
that file from 1. to simply 1 in your filesystem.
Without access to an OpenVMS system and having no real understanding
of Lucene's internals, I can't really look into it any more at this
point. You probably need to email the Lucene Users list and ask if
anyone has successfully gotten it to run on OpenVMS (I'm guessing not)
and get things patched up before you can make more progress with
getting Nexus running on it. Or take the more reasonable approach and
simply install Nexus on a Windows box in your office. ;-)
Wayne
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
where to put common dependecies in multi-module project
Hi,
i'm wondering where to put my common dependenies in my multimodule project.
Let's say, we have a project called sandbox, with three submodules.
- sandbox-core
- sandbox-service
- sandbox-web
Existing dependencies:
- sandbox-service has a dependency to sandbox-core
- sandbox-web has a dependency to sandbox-service
So practically, all dependencies of sandbox-core, will be transitive
dependencies for the other modules.
Let's say i want to use slf4j as logging framework, which should probable be
used in all modules and all of them should also use the same version.
I see different approaches on this:
- i could add the dependencies to the parent pom (sandbox)
- i could also only define a property for the version, e.g.
${slf4j.dependency.version} in the parent pom (sandbox) and actually add the
dependency on core level (sandbox-core)
- i could also simply add the dependency (plus version) to the core level
(sandbox-core)
I already had some problems, when not building the whole project (on
sandbox) level, that not all dependencies have been resolved in my leave
module (sandbox-web).
So i assume when putting the dependencies in the sandbox-core, one will
always have to build the whole project in order to have a working
sandbox-web module, while when putting them into the parent directly, the
dependencies would be retrieved by maven correctly anyway, since the
parent-poms are always taken intoconsideration, even when only the
sandbox-web is built.
So, what would be the best-practice on that?
What exact differences would be there between direct dependencies and
transitive dependencies?
Where should i put those common dependencies?
br
R.C.
--
View this message in context:
http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4931654.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: where to put common dependecies in multi-module project
Hi!
Define the versions of your dependencies in the parent's
dependencyManagement section. Define the actual dependency in every
submodule where you use it. Without the version!
The analyze goal of the maven-dependency-plugin can help you to find out if
you should declare a dependency or not.
hth,
- martin
On Monday 24 October 2011 codingplayer wrote:
Hi,
i'm wondering where to put my common dependenies in my multimodule
project.
Let's say, we have a project called sandbox, with three submodules.
- sandbox-core
- sandbox-service
- sandbox-web
Existing dependencies:
- sandbox-service has a dependency to sandbox-core
- sandbox-web has a dependency to sandbox-service
So practically, all dependencies of sandbox-core, will be transitive
dependencies for the other modules.
Let's say i want to use slf4j as logging framework, which should probable
be used in all modules and all of them should also use the same version.
I see different approaches on this:
- i could add the dependencies to the parent pom (sandbox)
- i could also only define a property for the version, e.g.
${slf4j.dependency.version} in the parent pom (sandbox) and actually add
the dependency on core level (sandbox-core)
- i could also simply add the dependency (plus version) to the core level
(sandbox-core)
I already had some problems, when not building the whole project (on
sandbox) level, that not all dependencies have been resolved in my leave
module (sandbox-web).
So i assume when putting the dependencies in the sandbox-core, one will
always have to build the whole project in order to have a working
sandbox-web module, while when putting them into the parent directly, the
dependencies would be retrieved by maven correctly anyway, since the
parent-poms are always taken intoconsideration, even when only the
sandbox-web is built.
So, what would be the best-practice on that?
What exact differences would be there between direct dependencies and
transitive dependencies?
Where should i put those common dependencies?
br
R.C.
--
View this message in context:
http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi
-module-project-tp4931654p4931654.html Sent from the Maven - Users mailing
list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
signature.asc
Description: This is a digitally signed message part.
Re: where to put common dependecies in multi-module project
Hi Martin, thanks for your hint to the pluginManagement section. But actually, that is not exaclty what i want. Since i do not want to repeat defining each common dependency separately for each sub-module. This approach would be ideal, if i want to use this dependency in many sub-modules (but not all), so i could skip the definition in those sub-modules, where i do not need it. If a want to have a new common dependecy which shall be used for all sub-modules, i could simply add this dependency to the parent-pom, right? Why would i rather put in it each module individually, what would be the benefits? And why not put it into the core module (e.g. sandbox-core) , since all other sub-modules would use the core anyway? br R.C. -- View this message in context: http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4931809.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: where to put common dependecies in multi-module project
If you actually use a dependency (in code) in a module, that dependency should always be a direct dependency of the module, either declared in the module itself or in a parent POM. From my experience, declaring dependencies (not dependencyManagement) in parent POMs comes with some disadvantages, but from your description it sounds like this approach is a good fit for you. In my case we had to do a lot of excludes in packaging modules (like ears, zips etc) before we changed to a more proper way of declaring dependencies. As for the other alternative you mention. Even if you have control over all the artifacts in the build, as you seem do in this case, relying on transitive dependencies from the core module for stuff you actually use in other modules is a bad approach. It does not express true intent, and conceptually these dependencies should be direct, as stated above. Also it leaves your other modules open for breakage if someone in the future intentionally or accidentally changes the core module in a way you did not anticipate. On Mon, Oct 24, 2011 at 11:08, codingplayer roman.ce...@smartengine.atwrote: Hi Martin, thanks for your hint to the pluginManagement section. But actually, that is not exaclty what i want. Since i do not want to repeat defining each common dependency separately for each sub-module. This approach would be ideal, if i want to use this dependency in many sub-modules (but not all), so i could skip the definition in those sub-modules, where i do not need it. If a want to have a new common dependecy which shall be used for all sub-modules, i could simply add this dependency to the parent-pom, right? Why would i rather put in it each module individually, what would be the benefits? And why not put it into the core module (e.g. sandbox-core) , since all other sub-modules would use the core anyway? br R.C. -- View this message in context: http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4931809.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- - Jan Fredrik Wedén
Central repository full index
Hi, We're using maven indexer formerly Nexus Indexer in our application. We used to have a ~0.5Gb index holding list of classes in each artifact. This information is not available anymore. Is there any chance of making such kind of index available again ? Many 10x, Edo Shor -- View this message in context: http://maven.40175.n5.nabble.com/Central-repository-full-index-tp4932465p4932465.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: where to put common dependecies in multi-module project
This is how we solve this problem in our case with a 70+ module project
with many 3rd party tools (Apache, JasperSoft, Spring, JBoss-Hibernate).
http://blog.artifact-software.com/tech/?p=121
Ron
On 24/10/2011 3:58 AM, codingplayer wrote:
Hi,
i'm wondering where to put my common dependenies in my multimodule project.
Let's say, we have a project called sandbox, with three submodules.
- sandbox-core
- sandbox-service
- sandbox-web
Existing dependencies:
- sandbox-service has a dependency to sandbox-core
- sandbox-web has a dependency to sandbox-service
So practically, all dependencies of sandbox-core, will be transitive
dependencies for the other modules.
Let's say i want to use slf4j as logging framework, which should probable be
used in all modules and all of them should also use the same version.
I see different approaches on this:
- i could add the dependencies to the parent pom (sandbox)
- i could also only define a property for the version, e.g.
${slf4j.dependency.version} in the parent pom (sandbox) and actually add the
dependency on core level (sandbox-core)
- i could also simply add the dependency (plus version) to the core level
(sandbox-core)
I already had some problems, when not building the whole project (on
sandbox) level, that not all dependencies have been resolved in my leave
module (sandbox-web).
So i assume when putting the dependencies in the sandbox-core, one will
always have to build the whole project in order to have a working
sandbox-web module, while when putting them into the parent directly, the
dependencies would be retrieved by maven correctly anyway, since the
parent-poms are always taken intoconsideration, even when only the
sandbox-web is built.
So, what would be the best-practice on that?
What exact differences would be there between direct dependencies and
transitive dependencies?
Where should i put those common dependencies?
br
R.C.
--
View this message in context:
http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4931654.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: where to put common dependecies in multi-module project
Hi Jan, i get it now, declaring the dependencies in the parent-pom (or directly in each module's pom, where it will be used) leads to a proper binding of the library to the modules, and everybody who changes this dependency, should then be aware of the influences on the code. While using transitive dependencies seem to be more or less hidden to those developers only using e.g. the web module. I also see the disadvantages (of the parent-pom approach) when you need to create some assembled artifacts. thanks for your help on this. br R.C. -- View this message in context: http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4932859.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: where to put common dependecies in multi-module project
On 24/10/2011 10:43 AM, codingplayer wrote: Hi Jan, i get it now, declaring the dependencies in the parent-pom (or directly in each module's pom, where it will be used) leads to a proper binding of the library to the modules, and everybody who changes this dependency, should then be aware of the influences on the code. That is one of the reasons why we use aggregation POMs. The decision about what versions of 3rd party tools will be used in the project is made at the team level and the developer only has to decide whether they need JasperReports or not. If they do, then they add a single dependency and know that it is correct and does not drag in any dependencies that conflict with the Apache utilities that are included through the utilities POM. While using transitive dependencies seem to be more or less hidden to those developers only using e.g. the web module. I also see the disadvantages (of the parent-pom approach) when you need to create some assembled artifacts. thanks for your help on this. br R.C. -- View this message in context: http://maven.40175.n5.nabble.com/where-to-put-common-dependecies-in-multi-module-project-tp4931654p4932859.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Expected behavior of the -f command line flag and working directories
Hi All, I am curious what the expected behavior with is when using the -f alternate-pom-file command line option with respect to the working directory. I am running 'mvn -f sub-dir/pom.xml' and it seems Maven will change the working directory to 'sub-dir' before executing the actual build. Is this intentional and by design? I had expected that the working directory to remain the same, while simply allowing you to place the pom files anywhere. Cheers, johan -- you too? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Profile activation based on property absence OR property value of false
It looks like activating a profile based on EITHER the absence of a property OR the presence of that property with a particular value is not possible. Is that correct? For example, suppose I wanted to add in a bunch of plugins if the skipTests property was (a) specified with a value of false or (b) not specified at all. It looks like I cannot activate a profile that takes (a) and (b) into account. Best, Laird -- http://about.me/lairdnelson
RE: Profile activation based on property absence OR property value of false
Yes you can, try: !true See http://svn.codehaus.org/mojo/trunk/mojo/sql-maven-plugin/pom.xml Date: Mon, 24 Oct 2011 17:30:24 -0400 Subject: Profile activation based on property absence OR property value of false From: ljnel...@gmail.com To: users@maven.apache.org It looks like activating a profile based on EITHER the absence of a property OR the presence of that property with a particular value is not possible. Is that correct? For example, suppose I wanted to add in a bunch of plugins if the skipTests property was (a) specified with a value of false or (b) not specified at all. It looks like I cannot activate a profile that takes (a) and (b) into account. Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problems with MAVEN's-ANT on OpenVMS
Thank you Wayne for this excellent Analysis. If a routine belonging to the file system returns something badly, there is a little chance to influence by a logical JAVA$FILENAME_CONTROL which can be set to so many values used to control filename encodings, particular how to deal with dot's in file names. I found some related comments that may be helpful to you... All this talk of OpenVMS brings me back to days at Uni on VAX/VMS boxen. ;-) http://h30499.www3.hp.com/t5/Languages-and-Scripting/Lucene-Solr-and-filepaths/td-p/4601881 and http://www.mediawiki.org/wiki/Extension_talk:Lucene-search/archive/2010#Lucene-search_on_OpenVMS It seems you will need to use some configuration along these lines: $ set proc/parse=extended $ @SYS$COMMON:[JAVA$150.COM]JAVA$150_SETUP.COM $ define DECC$ARGV_PARSE_STYLE ENABLE $ define DECC$EFS_CASE_PRESERVE ENABLE $ define DECC$POSIX_SEEK_STREAM_FILE ENABLE $ define DECC$EFS_CHARSET ENABLE $ define DECC$ENABLE_GETENV_CACHE ENABLE $ define DECC$FILE_PERMISSION_UNIX ENABLE $ define DECC$FIXED_LENGTH_SEEK_TO_EOF ENABLE $ define DECC$RENAME_NO_INHERIT ENABLE $ define DECC$ENABLE_TO_VMS_LOGNAME_CACHE ENABLE $ FILE_MASK = %x0008 + %x0004 $ DEFINE JAVA$FILENAME_CONTROLS 'file_mask' Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Cannot find ArtifactResolver with hint: project-cache-aware...NoSuchElementException
Greetings, Please excuse my ignorance surely on display in my email below. I am fairly new to maven. I am getting the error below: [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.artifact.resolver.ArtifactResolver roleHint: project-cache-aware at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247) Full text here: https://gist.github.com/1310602 also found in another GH Gist: https://gist.github.com/1248441 when executing the following commands (maven 3.0.3): mvn assembly:assembly mvn assembly:single The pom.xml and descriptor are below: https://svn.apache.org/repos/asf/incubator/mrunit/branches/mrunit-0.5.0/pom.xml https://svn.apache.org/repos/asf/incubator/mrunit/branches/mrunit-0.5.0/src/main/assembly/dist.xml Any ideas on how what I am doing wrong? I found this error a few places but the discussion was above my head. The goal of this work is build an artifact for an Apache Incubator project. Thank you for your time. Brock - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cannot find ArtifactResolver with hint: project-cache-aware...NoSuchElementException
I found my issue. User error. groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.2.1/version +configuration + descriptors +descriptorsrc/main/assembly/dist.xml/descriptor + /descriptors +/configuration executions execution -configuration - descriptors -descriptorsrc/main/assembly/dist.xml/descriptor - /descriptors -/configuration phasepackage/phase On Mon, Oct 24, 2011 at 6:09 PM, Brock Noland bro...@gmail.com wrote: Greetings, Please excuse my ignorance surely on display in my email below. I am fairly new to maven. I am getting the error below: [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.artifact.resolver.ArtifactResolver roleHint: project-cache-aware at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247) Full text here: https://gist.github.com/1310602 also found in another GH Gist: https://gist.github.com/1248441 when executing the following commands (maven 3.0.3): mvn assembly:assembly mvn assembly:single The pom.xml and descriptor are below: https://svn.apache.org/repos/asf/incubator/mrunit/branches/mrunit-0.5.0/pom.xml https://svn.apache.org/repos/asf/incubator/mrunit/branches/mrunit-0.5.0/src/main/assembly/dist.xml Any ideas on how what I am doing wrong? I found this error a few places but the discussion was above my head. The goal of this work is build an artifact for an Apache Incubator project. Thank you for your time. Brock - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
