Couldn't find a version in [6.5-m92322-115] to match range [6.5,)
Hi, I get the error message in the title when I try to build my plugin. According to my understanding the version 6.5-m92322-115 is included in the version range [6.5,). So what is the problem? Thanks, Shai -- View this message in context: http://www.nabble.com/Couldn%27t-find-a-version-in--6.5-m92322-115--to-match-range--6.5%2C%29-tp16379408s177p16379408.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Trouble generating the site
You have to use the form
maven.xdoc.jsl=file:/${basedir}/xdocs/site.jsl
in project.properties, this will find the style sheet. However, I'm
still getting a build error after that, so before I dig into it: do you
really need the custom style sheet? The site builds fine with the
default jsl.
-Lukas
Craig L Russell wrote:
Hi,
We are using maven to generate the Apache JDO site
(http://svn.apache.org/viewvc/db/jdo/site/ ).
We upgraded from Maven 1.0.2 to Maven 1.1 and the site no longer
generates.
The full console output is below [1].
The error message is
Unable to obtain goal [site]
/Users/clr/.maven/cache/maven-xdoc-plugin-1.10.1/xdocs/site.jsl (No
such file or directory)
Any ideas?
Thanks,
Craig
Begin forwarded message:
From: Andy Jefferson [EMAIL PROTECTED]
Date: March 29, 2008 12:42:14 AM PDT
To: [EMAIL PROTECTED]
Subject: Re: Trouble generating the site
Reply-To: [EMAIL PROTECTED]
Hi,
I use Maven 1.0.2 (what I've used for the last 4 yrs ... since it
works and I
don't trust the (lack of) backwards compatibility concerns of the Maven
project
I see the same error as Craig if I run 'maven site' in jdo/site. I also
have a site.jsl in my
.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources. But there is a
(different) site.jsl checked in into jdo/site/xdocs. In addition the
file project.properties in jdo/site defines a property
'maven.xdoc.jsl=xdocs/site.jsl'. If I delete this property 'maven site'
succeds.
There is a different site.jsl checked in to xdocs because that is
there to
override the default site generation of Maven1. Without it you get a
chunky
site with none of the refinements that were added ;-)
maven-xdoc-plugin is *supposed* to allow overriding the default
stylesheet via
the property maven.xdoc.jsl (not that they can be bothered to document
it) ... hence why it is in project.properties pointing to ours. It
currently
doesn't have ${basedir} prepended and maybe should have (but that
doesn't
solve this issue anyway so ignore that).
The maven-xdoc-plugin bundled with Maven1.0.2 accepts that
overriding. The one
that comes with Maven1.1 accepts it so far (since it even prints out
the site.jsl it will use ... correctly) but then tries to append
that name
on the end of the plugin workspace!!! duh.
If you chase the process through the plugin.jelly of that plugin you
get to
x:parse var=doc xml=${file}/
j:file name=${outFile} encoding=${outputencoding}
omitXmlDeclaration=true outputMode=xml
prettyPrint=no
j:include uri=${stylesheet.toString()}/
/j:file
which has the correct stylesheet name going in (ours). Where that
then goes to
I've no idea.
Maybe some Maven team member could comment, and there's some secret
setting
that you have to use to get it to work with your own site.jsl file in
Maven
1.1 ?
--
Andy (Java Persistent Objects - http://www.jpox.org)
[1]
[CraigRussell:~/apache/jdo/site] clr% svn status
[CraigRussell:~/apache/jdo/site] clr% svn up
At revision 642332.
[CraigRussell:~/apache/jdo/site] clr% maven clean
site __ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1
build:start:
clean:clean:
xdoc:clean:
clean:
site:
xdoc:register-reports:
maven-javadoc-plugin:register:
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/javadoc
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/javadoc/src
site:run-reports:
xdoc:init-i18n:
[echo] Init the i18n support
xdoc:init:
[echo] Generates the directory structure required for xdocs
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/generated- xdocs
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/docs
xdoc:i18n-validation:
[echo] Validation of the locale entries
xdoc:register-reports:
maven-javadoc-plugin:register:
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:transform:
xdoc:init-i18n:
xdoc:init:
[echo] Generates the directory structure required for xdocs
xdoc:copy-resources:
[copy] Copying 5 files to /Users/clr/apache/jdo/site/target/docs/ style
[copy] Copying 16 files to /Users/clr/apache/jdo/site/target/docs/
images
xdoc:init-i18n:
xdoc:init:
[echo] Generates the directory structure required for xdocs
Copying user supplied resources.
xdoc:copy-user-resources:
[copy] Copying 17 files to /Users/clr/apache/jdo/site/target/docs
[copy] Copied 3 empty directories to 2 empty directories under /
Users/clr/apache/jdo/site/target/docs
xdoc:init-i18n:
xdoc:init:
[echo] Generates the directory structure required for xdocs
xdoc:jelly-init:
xdoc:register-reports:
maven-javadoc-plugin:register:
xdoc:jelly-transform:
About to use JSL stylesheet xdocs/site.jsl
[echo] en
[echo] The current Locale is the default one
[echo] Scanning '/Users/clr/apache/jdo/site/target/generated- xdocs'...
[echo] Generating /Users/clr/apache/jdo/site/target/docs/
Re: Couldn't find a version in [6.5-m92322-115] to match range [6.5,)
No, its not included. 6.5-something is regarded as before 6.5 Henry On 3/30/08, carioca [EMAIL PROTECTED] wrote: Hi, I get the error message in the title when I try to build my plugin. According to my understanding the version 6.5-m92322-115 is included in the version range [6.5,). So what is the problem? Thanks, Shai -- View this message in context: http://www.nabble.com/Couldn%27t-find-a-version-in--6.5-m92322-115--to-match-range--6.5%2C%29-tp16379408s177p16379408.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven - new entrant! - a quick question
I've started using and reading docs on Maven. While using and also while referring docs, realized that, when maven is being used for the first time, it downloads a lot of artifacts (jars, poms, etc). I wanted to find out whether it is a must to have internet connection while using maven? For example, how will you suggest to use maven for the first time on a production environment, where for sure there'll not be an internet connection or a proxy available to download something from the net across the firewall. How do you suggest to handle such a scenario? Thanks! SK -- View this message in context: http://www.nabble.com/maven---new-entrant%21---a-quick-question-tp16379510s177p16379510.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven - new entrant! - a quick question
;On Sun, Mar 30, 2008 at 02:46:11AM -0700, SKService wrote: I've started using and reading docs on Maven. While using and also while referring docs, realized that, when maven is being used for the first time, it downloads a lot of artifacts (jars, poms, etc). I wanted to find out whether it is a must to have internet connection while using maven? For example, how will you suggest to use maven for the first time on a production environment, where for sure there'll not be an internet connection or a proxy available to download something from the net across the firewall. How do you suggest to handle such a scenario? Deploy the content of $HOME/.m2/repository from development host to production $HOME/.m2/repository. Probably wipe out unnecessary dependencies. -- Eugene N Dzhurinsky pgphMF9H45vbp.pgp Description: PGP signature
Re: how set manifestEntries with maven-assembly-plugin
I want to do the exact same,
but it seems that the assembly plugin only accepts
manifest
addDefaultImplementationEntriestrue/addDefaultImplementationEntries
addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
/manifest
which does not include the
X-Compile-Source-JDK${maven.compile.source}/X-Compile-Source-JDK
X-Compile-Target-JDK${maven.compile.target}/X-Compile-Target-JDK
manifestEntries.
Anybody have a clue for this?
Rex Huang wrote:
I use maven-assembly-plugin instead of maven-jar-plugin,
because I want to create a binary distribution with all runtime
dependencies.
but I don't know how set manifestEntries with maven-assembly-plugin.
and also I wonder if the sunfire-test is test the jar file that I
repackaged
with maven-assembly-plugin.
BR//Rex
--
View this message in context:
http://www.nabble.com/how-set-manifestEntries-with-maven-assembly-plugin-tp15566039s177p16380812.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. -dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : [deploy-plugin] Abort deploy when a target is present
Hi all, If some people were still interested in this subject, I found the codecommit Brian was speaking about. I also commented the bug I logged: http://jira.codehaus.org/browse/MDEPLOY-74?focusedCommentId=129147#action_129147 The related improvement request (logged by Jason): http://jira.codehaus.org/browse/MARTIFACT-6 With this modification, at the moment, the situation will be reversed: you won't be able to redeploy an artifact that has already been deployed (no problem for snapshot, which is taken apart). So, don't do mistakes :). You'll have to connect to your repository and manually deploy the wrong artifact(s). Anyway, Imo, it's actually far better to have no option in this case than in the old one (being able to redeploy any time you want). Cheers. -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Fri 3/28/2008 2:59 PM To: Maven Users List Subject: RE: RE : [deploy-plugin] Abort deploy when a target is present I'd have to check on this. I know in 2.1 it's on by default and there is no way to force it. Perhaps Jason put it in the wagon manager or something and not the plugin. -Original Message- From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2008 2:53 AM To: Maven Users List Subject: RE : [deploy-plugin] Abort deploy when a target is present Great news! I had a quick look on https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ and did not see any log related to it. So was there already a logged bug about this: http://jira.codehaus.org/browse/MDEPLOY-74 What/where is the new code, some 3.x or something? So, is there another svn repository for this? In fact, I'd be happy to be able to either use a new released version or help merging back this feature if possible. Cheers Message d'origine De: Brian E. Fox [mailto:[EMAIL PROTECTED] Date: jeu. 27/03/2008 18:45 À: Maven Users List Objet : RE: [deploy-plugin] Abort deploy when a target is present This is the default in the new code, but it wasn't merged back to 2.0.x I believe. -Original Message- From: MATHUS Baptiste [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 9:32 AM To: Maven Users List Subject: [deploy-plugin] Abort deploy when a target is present Hi all, Recently, some developers did a release manually. So they put a release version in the pom and triggered a deploy. Everything fine but... The thing is: they forgot to re-update the pom.version to a new snapshot version. So, as the code is continuously integrated, at each new commit, the recent release was automatically overridden many times with the snapshot code before realizing it :-/. So, what I would like is to be able to put an additional option for maven when run inside the continuous integration server, something like -DdontOverrideRelease, that would make fail the deployment if the released artefact is already present. I've taken a quick look at http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html but it seems it's not currently possible. What do you think? Can a file an feature request about it in the plugin tracker? Thanks a lot. Cheers. -- Baptiste - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Passing parameters to maven classes
Hi all,
I've got some small questions about plugin development. More particularly about
passing parameters.
If you think this question should better be asked on the mvn-dev ML, please let
me know.
I saw how to do it for a mojo: according to a declaration like this:
/**
* @parameter expression=${project.packaging}
* @required
* @readonly
*/
plexus, the IoC framework used by maven will then pass the requested -D params
to the mojo.
But what about maven core projects (how do you call it, btw? Maven core?
Non-mojo? maven api?). For example, say I want that a -Dvar=value variable be
passed to some maven code that's not a mojo (wagon-provider-api, maven-artifact
e.g.). Some switch that I would like to use in this maven api code.
What's the practice to do it?
Should I manage the parameter in the mojo, and then add a parameter in the
non-mojo code to pass the retrieved value from the calling mojo to the api code?
Should I use some special configurer from plexus to inject system property
directly into the api code?
Thanks a lot in advance.
Cheers.
-- Baptiste
Re: Best practices for java version?
Dirk Olmes a écrit : Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. -dirk So, can we consider that a successfull build using a 1.4 JDK + source and target in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? David Delbecq - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
delbd wrote: Dirk Olmes a écrit : Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. So, can we consider that a successfull build using a 1.4 JDK + source and target in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? Not really. After a successful build with JDK1.4 you know that none of your direct dependencies (the ones you're importing in your Java classes) don't use JDK5. At runtime this may be a completely different story as transitive dependencies on which you don't have compile time dependencies might still be JDK5. You *might* be safe once all your tests run green on JDK1.4 as well but that requires proper coverage, of course. -dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Fixing not finding maven-resources-plugin
That appeared to resolve the problem. From: Kedar Mhaswade [mailto:[EMAIL PROTECTED] Sent: Sat 03/29/2008 3:35 PM To: Maven Users List Subject: Re: Fixing not finding maven-resources-plugin Karr, David wrote: I know very little about maven2. I'm trying to step through a Struts2 tutorial (Ian Roughley's book). After executing the following: mvn archetype:create -DgroupId=com.fdar.apress.s2 -DartifactId=struts2-starter -DarchetypeGroupId=org.apache.struts -DarchetypeArtifactId=struts2-archetype-starter -DarchetypeVersion=2.0.9-SNAPSHOT -DremoteRepositories=http://people.apache.org/maven-snapshot-repository I then did mvn jetty:run, and it said: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found What would be the correct way to resolve this? Could the original command-line have been amended to avoid this in the first place? Can you try mvn -U jetty:run instead? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
Dirk Olmes a écrit : delbd wrote: Dirk Olmes a écrit : Graham Leggett wrote: Richard Chamberlain wrote: I agree it's not ideal, but I'm open to suggestions as to how to guarantee code from a particular project works in a java 1.4 environment? Use Continuous Integration and a test suite. That's what we do here, too. We use profiles that are auto-activated by the JDK type and have modules declarations only inside the profiles. WE evaluated going through the hassle of specifying the RT jar etc but in the end decided that it wouldn't be worthwhile so we just use -source and -target to bulid. Our CI server has two build plans: one for regular JDK5 builds (that runs on a JDK5) and on that runs nightly (on a JDK1.4) ensuring JDK1.4 source compatability for the modules that require it. Even greater care must be taken now when managing the dependecies: does any module bring in JDK5 compatible third party deps in? Do JDK14 modules depend on JDK5 modules? Cross-JDK builds are doable with Maven, is's just another pile of complexity on top of what you're already having to deal with. So, can we consider that a successfull build using a 1.4 JDK + source and target in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? Not really. After a successful build with JDK1.4 you know that none of your direct dependencies (the ones you're importing in your Java classes) don't use JDK5. At runtime this may be a completely different story as transitive dependencies on which you don't have compile time dependencies might still be JDK5. You *might* be safe once all your tests run green on JDK1.4 as well but that requires proper coverage, of course. Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I think it should be possible for a dependency to specify that it aims a specific jvm and as such if a project aims a lower dependency, you'll have a conflict that would appear in report (there is already such report for regular dependencies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
On 3/30/08, delbd [EMAIL PROTECTED] wrote: Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I Check JIRA, and if its not already posted, file it. Perhaps it can be incorporated in 2.1. Or, perhaps there's already a way to do it that I haven't considered... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
check the toolchains proposal that is supposed to address this issue. http://docs.codehaus.org/display/MAVEN/Toolchains Milos Kleint On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay [EMAIL PROTECTED] wrote: On 3/30/08, delbd [EMAIL PROTECTED] wrote: Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I Check JIRA, and if its not already posted, file it. Perhaps it can be incorporated in 2.1. Or, perhaps there's already a way to do it that I haven't considered... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
delbd wrote: So, can we consider that a successfull build using a 1.4 JDK + source and target in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? No, but a test suite can. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
[m2] Tomcat Cargo logs location?
I am running Tomcat via Cargo for integration tests in Maven. I keep getting 400 errors running an XFire test and says to refer to the logs: *![CDATA[org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Server returned error code = 400 for URI : http://localhost:8080/services/Echo. Check server logs for details org.codehaus.xfire.fault.XFireFault: Server returned error code = 400 for URI : http://localhost:8080/services/Echo. Check server logs for details * Where would I go to find these logs? I looked in C:\opt\temp\appfuse\myproject\web\target\tomcat5x\container\logs\localhost_access_log.2008-03-30 but there was nothing but: *127.0.0.1 - - [30/Mar/2008:11:37:10 -0700] GET /cargocpc/index.html HTTP/1.1 200 124 127.0.0.1 - - [30/Mar/2008:11:37:10 -0700] GET /cargocpc/index.html HTTP/1.1 200 124 127.0.0.1 - - [30/Mar/2008:11:37:10 -0700] GET /cargocpc/index.html HTTP/1.1 200 124* -- Thanks, Mick Knutson http://www.baselogic.com http://www.blincmagazine.com http://www.linkedin.com/in/mickknutson http://www.djmick.com http://www.myspace.com/mickknutson http://www.myspace.com/BLiNCMagazine http://tahoe.baselogic.com ---
Re: Fwd: Trouble generating the site
I had a closer look at this (bugged me because I remember working on a
fix for custom style sheets before m1.1... ;) )
One issue you might experience concerns the number of slashes in the
file url prefix. Depending on your OS, especially on different Windows
versions, you might need
maven.xdoc.jsl=file://${basedir}/xdocs/site.jsl
or even three slashes.
The second problem is that you have an xpath syntax error in your custom
style sheet, line 154 in site.jsl should read:
jsl:applyTemplates select=$nav/body/menu[not(@type)] |
$nav/body/[EMAIL PROTECTED]'header'] | $nav/body/search/
With that the jdo site builds fine for me.
HTH,
-Lukas
Lukas Theussl wrote:
You have to use the form
maven.xdoc.jsl=file:/${basedir}/xdocs/site.jsl
in project.properties, this will find the style sheet. However, I'm
still getting a build error after that, so before I dig into it: do you
really need the custom style sheet? The site builds fine with the
default jsl.
-Lukas
Craig L Russell wrote:
Hi,
We are using maven to generate the Apache JDO site
(http://svn.apache.org/viewvc/db/jdo/site/ ).
We upgraded from Maven 1.0.2 to Maven 1.1 and the site no longer
generates.
The full console output is below [1].
The error message is
Unable to obtain goal [site]
/Users/clr/.maven/cache/maven-xdoc-plugin-1.10.1/xdocs/site.jsl
(No such file or directory)
Any ideas?
Thanks,
Craig
Begin forwarded message:
From: Andy Jefferson [EMAIL PROTECTED]
Date: March 29, 2008 12:42:14 AM PDT
To: [EMAIL PROTECTED]
Subject: Re: Trouble generating the site
Reply-To: [EMAIL PROTECTED]
Hi,
I use Maven 1.0.2 (what I've used for the last 4 yrs ... since it
works and I
don't trust the (lack of) backwards compatibility concerns of the Maven
project
I see the same error as Craig if I run 'maven site' in jdo/site. I
also
have a site.jsl in my
.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources. But there is a
(different) site.jsl checked in into jdo/site/xdocs. In addition the
file project.properties in jdo/site defines a property
'maven.xdoc.jsl=xdocs/site.jsl'. If I delete this property 'maven
site'
succeds.
There is a different site.jsl checked in to xdocs because that is
there to
override the default site generation of Maven1. Without it you get a
chunky
site with none of the refinements that were added ;-)
maven-xdoc-plugin is *supposed* to allow overriding the default
stylesheet via
the property maven.xdoc.jsl (not that they can be bothered to
document
it) ... hence why it is in project.properties pointing to ours. It
currently
doesn't have ${basedir} prepended and maybe should have (but that
doesn't
solve this issue anyway so ignore that).
The maven-xdoc-plugin bundled with Maven1.0.2 accepts that
overriding. The one
that comes with Maven1.1 accepts it so far (since it even prints out
the site.jsl it will use ... correctly) but then tries to append
that name
on the end of the plugin workspace!!! duh.
If you chase the process through the plugin.jelly of that plugin you
get to
x:parse var=doc xml=${file}/
j:file name=${outFile} encoding=${outputencoding}
omitXmlDeclaration=true outputMode=xml
prettyPrint=no
j:include uri=${stylesheet.toString()}/
/j:file
which has the correct stylesheet name going in (ours). Where that
then goes to
I've no idea.
Maybe some Maven team member could comment, and there's some secret
setting
that you have to use to get it to work with your own site.jsl file
in Maven
1.1 ?
--
Andy (Java Persistent Objects - http://www.jpox.org)
[1]
[CraigRussell:~/apache/jdo/site] clr% svn status
[CraigRussell:~/apache/jdo/site] clr% svn up
At revision 642332.
[CraigRussell:~/apache/jdo/site] clr% maven clean
site __ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.1
build:start:
clean:clean:
xdoc:clean:
clean:
site:
xdoc:register-reports:
maven-javadoc-plugin:register:
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/javadoc
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/javadoc/src
site:run-reports:
xdoc:init-i18n:
[echo] Init the i18n support
xdoc:init:
[echo] Generates the directory structure required for xdocs
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/generated-
xdocs
[mkdir] Created dir: /Users/clr/apache/jdo/site/target/docs
xdoc:i18n-validation:
[echo] Validation of the locale entries
xdoc:register-reports:
maven-javadoc-plugin:register:
xdoc:generate-from-pom:
[echo] Generating xdocs from POM ...
xdoc:transform:
xdoc:init-i18n:
xdoc:init:
[echo] Generates the directory structure required for xdocs
xdoc:copy-resources:
[copy] Copying 5 files to /Users/clr/apache/jdo/site/target/docs/
style
[copy] Copying 16 files to /Users/clr/apache/jdo/site/target/docs/
images
xdoc:init-i18n:
xdoc:init:
[echo] Generates the directory structure
Re: [m2] Tomcat Cargo logs location?
On Sun, Mar 30, 2008 at 11:54 AM, Mick Knutson [EMAIL PROTECTED] wrote: I am running Tomcat via Cargo for integration tests in Maven. The Cargo project has its own mailing lists, you can find subscription info here: http://cargo.codehaus.org/Mailing+Lists -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven - new entrant! - a quick question
I think using a maven proxy like artifactory is a better option. On Sun, Mar 30, 2008 at 11:59 AM, Eugeny N Dzhurinsky [EMAIL PROTECTED] wrote: ;On Sun, Mar 30, 2008 at 02:46:11AM -0700, SKService wrote: I've started using and reading docs on Maven. While using and also while referring docs, realized that, when maven is being used for the first time, it downloads a lot of artifacts (jars, poms, etc). I wanted to find out whether it is a must to have internet connection while using maven? For example, how will you suggest to use maven for the first time on a production environment, where for sure there'll not be an internet connection or a proxy available to download something from the net across the firewall. How do you suggest to handle such a scenario? Deploy the content of $HOME/.m2/repository from development host to production $HOME/.m2/repository. Probably wipe out unnecessary dependencies. -- Eugene N Dzhurinsky
RE: Best practices for java version?
I bet the dependency plugin and/or the enforcer could use ASM to inspect all transitive dependencies to check the class version. (I'm just guessing that ASM can do this). -Original Message- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Sunday, March 30, 2008 2:47 PM To: Maven Users List Subject: Re: Best practices for java version? delbd wrote: So, can we consider that a successfull build using a 1.4 JDK + source and target in build are enough to guarantee that none of the transitive dependencies require jre 5 or higher? No, but a test suite can. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
rmic-maven-plugin issues
Hi guys, I'm attempting to build an RMI client/server JAR. It doesn't appear to be making the client JAR correctly, because it doesn't include the interfaces of my RMI objects. The server JAR turns out just fine, and has all classes, which is exactly what I want. I also want to know how I'm supposed to get the client JAR in as a dependency to another project. When I put the rmi project as a dependency, it pulls in the full RMI server JAR. I also noticed that there is an error in the documentation under the Using the package goal section. The excludes need to be inside of a configuration element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven - new entrant! - a quick question
On Sun, Mar 30, 2008 at 9:24 PM, Eugeny N Dzhurinsky [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 09:05:01PM +0200, Siarhei Dudzin wrote: I think using a maven proxy like artifactory is a better option. Artifactory is a pain, give a try to Apache Archiva -- Eugene N Dzhurinsky Actually use Artifactory for quite some time and have no 'pain' with it. It didn't give us any reason to look for something else. Anyway I would look at *all* of them to be able to choose which one suits the needs. There is an article (it's a year old though, but comments still seem to be coming) that may get a beginner started with a very short overview of repository management systems: http://raibledesigns.com/rd/entry/artifactory_a_new_maven_2 It lists a few systems - enough to give a starting point in choosing the right one. Siarhei
Re: [m2] Tomcat Cargo logs location?
I'm on the Cargo Users list too, and the amount of traffic there vs here is just nothing, a couple posts a week and many don't get responded to. So I can understand why people post Cargo (in Maven) questions here. BUT I think it is a better idea long-term to push those questions to the proper place and grow that user list, than to simply allow them to be posted here. So, I agree with Wendy. ;-) Wayne On 3/30/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 11:54 AM, Mick Knutson [EMAIL PROTECTED] wrote: I am running Tomcat via Cargo for integration tests in Maven. The Cargo project has its own mailing lists, you can find subscription info here: http://cargo.codehaus.org/Mailing+Lists -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deleting things out of a repository
What's the best way to remove, say, 10 or so old builds out of the repository (a locally run/managed one)? is there a mvn undeploy command?
Re: deleting things out of a repository
On Sun, Mar 30, 2008 at 1:41 PM, EJ Ciramella [EMAIL PROTECTED] wrote: What's the best way to remove, say, 10 or so old builds out of the repository (a locally run/managed one)? is there a mvn undeploy command? Can you explain more about what you're looking for? Are these snapshots or releases? (And is this a remote repository, or ~/.m2/repository?) Two things that come to mind are Apache Archiva's ability to purge snapshots from the repos it manages, and the recent discussions of the need for a tool to keep the local repo size under control. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eclipse 3.2.2 jars in central, what about RCP SDKs?
We develop RCP applications and it is handy that the Eclipse jars are now on central, can we get some of the RCP archives up as well? As per the downloads at http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php We need the eclipse-RCP-3.2.2 for our environment (eclipse-RCP-3.2.2-win32.zip) as well as the delta pack (eclipse-RCP-3.2.2-delta-pack.zip) These don't appear to be available on central (At least I couldn't find them easily). Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: eclipse 3.2.2 jars in central, what about RCP SDKs?
you would need to run eclipse:to-maven with the 2.5 plugin and put them somewhere to be synced On Sun, Mar 30, 2008 at 4:13 PM, Barrie Treloar [EMAIL PROTECTED] wrote: We develop RCP applications and it is handy that the Eclipse jars are now on central, can we get some of the RCP archives up as well? As per the downloads at http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php We need the eclipse-RCP-3.2.2 for our environment (eclipse-RCP-3.2.2-win32.zip) as well as the delta pack (eclipse-RCP-3.2.2-delta-pack.zip) These don't appear to be available on central (At least I couldn't find them easily). Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: eclipse 3.2.2 jars in central, what about RCP SDKs?
I've been busy but before anyone publishes anything I'll try to summarize the meeting we had at EclipseCon. In a nutshell the OSGi experts around the table like Peter Krien's, and Jeff McAffer agreed aligning the artifact id in Maven with the symbolic id is the way to go in the future. I'll do the summary some time this week. Nothing should be published until this agreed upon method is embodied in the tooling. On 30-Mar-08, at 4:39 PM, Carlos Sanchez wrote: you would need to run eclipse:to-maven with the 2.5 plugin and put them somewhere to be synced On Sun, Mar 30, 2008 at 4:13 PM, Barrie Treloar [EMAIL PROTECTED] wrote: We develop RCP applications and it is handy that the Eclipse jars are now on central, can we get some of the RCP archives up as well? As per the downloads at http://archive.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php We need the eclipse-RCP-3.2.2 for our environment (eclipse-RCP-3.2.2-win32.zip) as well as the delta pack (eclipse-RCP-3.2.2-delta-pack.zip) These don't appear to be available on central (At least I couldn't find them easily). Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
Milos Kleint wrote: check the toolchains proposal that is supposed to address this issue. http://docs.codehaus.org/display/MAVEN/Toolchains The way the toolchain proposal chooses is somewhat doable with Maven right now: define a set of VM specific properties in each developers' settings.xml and use that in the config of the various plugins. What I don't like about the appraoch is that one has to hand-maintain the properties/toolchain.xml still. If I update my JDK, I still have to remember updating the settings or the build will break. The great benefit of the toolchain approach is that it provides a standard definition of the JDK and that could also abstract from some platform specific difficulties (rt.jar on linux/win vs classes.jar on Mac). Still, I don't like the way how I have to manually distribute the path to the current JDK into various config files. -dirk Milos Kleint On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay [EMAIL PROTECTED] wrote: On 3/30/08, delbd [EMAIL PROTECTED] wrote: Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I Check JIRA, and if its not already posted, file it. Perhaps it can be incorporated in 2.1. Or, perhaps there's already a way to do it that I haven't considered... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: eclipse 3.2.2 jars in central, what about RCP SDKs?
On Mon, Mar 31, 2008 at 10:21 AM, Jason van Zyl [EMAIL PROTECTED] wrote: I've been busy but before anyone publishes anything I'll try to summarize the meeting we had at EclipseCon. In a nutshell the OSGi experts around the table like Peter Krien's, and Jeff McAffer agreed aligning the artifact id in Maven with the symbolic id is the way to go in the future. I'll do the summary some time this week. Nothing should be published until this agreed upon method is embodied in the tooling. Ok. I'll go back to my internal repo for now then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote: Still, I don't like the way how I have to manually distribute the path to the current JDK into various config files. you have to anyway it just happens you set an environment variable which is a bit average at the best of times. Packaged OS's do most of the hard work for you e.g. Gentoo manages the JAVA_HOME, MAVEN_HOME during script invocation, I think debian based linuxes do as well -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs ssh problem
Given this scm entry from a pom:
scm
connection
scm:cvs:ext:${cvs.user)@
freehost3270.org:/home/jstrayer/cvsroot:freehost3270
/connection
/scm
when I execute
mvn scm:update
It just hangs as if it's waiting for a password somewhere.
But when I execute
ssh [EMAIL PROTECTED]
I am connected without a password prompt.
I'm running in cygwin, so there might be a problem there. But I also tried
in a Windows shell (/cygwin/bin/ssh [EMAIL PROTECTED]) and I was
able to log in then too.
What do I need to look at next?
--
Esse Quam Videre
To Be, rather than to Seem
Re: Best practices for java version?
Michael McCallum wrote: On Mon, 31 Mar 2008 14:57:43 Dirk Olmes wrote: Still, I don't like the way how I have to manually distribute the path to the current JDK into various config files. you have to anyway it just happens you set an environment variable which is a bit average at the best of times. Good point. Packaged OS's do most of the hard work for you e.g. Gentoo manages the JAVA_HOME, MAVEN_HOME during script invocation, I think debian based linuxes do as well I'm a big fan of gentoo in this area and already make good use of java-config-2 in my custom scripts. What about those poor Windows users, though? I know I'm a bit philosophical here ... Anyway, I have just voted for the respective JIRA (MNG-468) and can't wait to get my hands on Maven 2.1 with toolchain support :-) -dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs ssh problem
On Mon, Mar 31, 2008 at 12:31 PM, Jon Strayer [EMAIL PROTECTED] wrote:
Given this scm entry from a pom:
scm
connection
scm:cvs:ext:${cvs.user)@
freehost3270.org:/home/jstrayer/cvsroot:freehost3270
/connection
/scm
when I execute
mvn scm:update
It just hangs as if it's waiting for a password somewhere.
But when I execute
ssh [EMAIL PROTECTED]
I am connected without a password prompt.
I'm running in cygwin, so there might be a problem there. But I also tried
in a Windows shell (/cygwin/bin/ssh [EMAIL PROTECTED]) and I was
able to log in then too.
What do I need to look at next?
Have you tried
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-plugin/artifactId
configuration
providerImplementations
cvscvs_native/cvs
/providerImplementations
/configuration
/plugin
There is something I remember about mvn using an internal cvs tool
until you set this value.
Can't recall the exact details now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practices for java version?
On Mon, Mar 31, 2008 at 2:57 AM, Dirk Olmes [EMAIL PROTECTED] wrote: Milos Kleint wrote: check the toolchains proposal that is supposed to address this issue. http://docs.codehaus.org/display/MAVEN/Toolchains The way the toolchain proposal chooses is somewhat doable with Maven right now: define a set of VM specific properties in each developers' settings.xml and use that in the config of the various plugins. toolchains also ensures that any plugin that understands toochains will ue them, thus instead of configuring compiler-plugin, surefire-plugin, javadoc-plugin etc. you just configure the toolchain. What I don't like about the appraoch is that one has to hand-maintain the properties/toolchain.xml still. If I update my JDK, I still have to remember updating the settings or the build will break. oh well, what do you mean by update my jdk? the default jdk you run stuff with on your computer? that's a scenario that works even now. If you don't configure anything in maven but make sure you run with the jdk you want, you're safe. The toolchains proposal tries to separate the jdk you run maven build with and the jdk that shall be used to build your project. That's essential in embedded environment for example. Milos The great benefit of the toolchain approach is that it provides a standard definition of the JDK and that could also abstract from some platform specific difficulties (rt.jar on linux/win vs classes.jar on Mac). Still, I don't like the way how I have to manually distribute the path to the current JDK into various config files. -dirk Milos Kleint On Sun, Mar 30, 2008 at 7:58 PM, Wayne Fay [EMAIL PROTECTED] wrote: On 3/30/08, delbd [EMAIL PROTECTED] wrote: Yeah, that's what i thought. So we can consider that maven is missing one important thing in dependency management: the jvm dependency. I Check JIRA, and if its not already posted, file it. Perhaps it can be incorporated in 2.1. Or, perhaps there's already a way to do it that I haven't considered... Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
