Re: resources:testResources not filtering files
The test resources go to a different directory, so they have a
different section (testResources)
src/main/resources
true
src/test/resources
true
On Nov 21, 2007 9:09 PM, Chad Boyd <[EMAIL PROTECTED]> wrote:
> When I run the goal resources:testResources a file in src/test/
> resources is copied to target/test-classes but isn't filtered. I have
> the src/test/resources directory listed in the pom with filtered set
> to true but the ${...} properties are still in the output file. When
> I run resources:resources it filters as expected. I'm setting the
> property values in my settings.xml file under the default profile and
> have verified that they are being recognized using mvn help:effective-pom
> . Here is a simple example you can use to reproduce:
>
> pom.xml:
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> "
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd
> ">
>4.0.0
>testProj
>testProj
>1.0-SNAPSHOT
>Archetype - testProj
>http://maven.apache.org
>
>
>
> src/main/resources
> true
>
>
> src/test/resources
> true
>
>
>
>
>
> contents of test.properties located in src/test/resources:
> prop=${prop.value}
>
> Now run "mvn -Dprop.val=test resources:testResources" and look at the
> output file target/test-classes/test.properties. The variable $
> {prop.val} isn't replaced. Anyone have any ideas as to what might be
> going wrong?
>
> -
> 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: restrict GPL/BSD licenses
It all depends on how the corporate legal brains interpret these things. Advocate #1: jar files are just dynamic link libraries... most of the open source licenses (including AFAIR the GPL) say dynamic linking is ok, static linking is less so... there is no problem here! Advocate #2: What about if you build a war or ear and have the jar in the lib folder? Now your code is statically linked to that jar. There is a problem here! Advocate #1: Ahh but the war and ear specs allow and expect for deployers to repackage, it's just a zip file after all, so they can replace a jar with a non-restrictive license, therefore it is dynamic linking. Are you saying that if I zip up a GPL product and a non-GPL product in the same zip file that my non-GPL is now GPL'ed? There is no problem here! Advocate #2: [More legal speak]... I've worked for companies where they take #1's side and others where it's #2 who wins. Additionally, there are issues with patents. In reality, an ethical developer should ensure that each shipped dependency is OK'ed by legal before you ship. OK'ed that the license is compatible with the company, OK'ed that the license terms have been met with, OK'ed that the dependency does not knowingly infringe any patents to which the company does not have a license (in the economic areas that the company intends to ship) What I think you need, therefore, is a maven-prerelease-legal-check-plugin that checks all dependencies against a "dependency is ok" legal database held by the company. The "dependency is ok" would just be a simple list of artifacts with version ranges. -Stephen On Nov 23, 2007 8:18 AM, maarten roosendaal <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering that if you make an application for a large corporate firm > using Maven 2, what problems can you expect regarding licenses of > (transitive) dependencies. Some licenses force you to make the application > you made, based on their open source product, open source and make it > available to the community. The corporate firm probably will not be amused by > this but it could lead to legal issues. I'm not too familair with all > licenses but this point was made by someone who does know a lot. > > Is there a way to enforce this with Maven (probably not) or should you do > something with the blacklist of say Archiva. > > Your thoughts on this? > > Maarten > > > > > > > Get easy, one-click access to your favorites. > Make Yahoo! your homepage. > http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: overriding jspc-maven-plugin
Put your config in a and that way the war projects
need only specify
org.codehaus.mojo.jspc
jspc-maven-plugin
and they'll pick up the config from the plugin management section.
Alternatively, use two parent poms, one for the jars and the other for the wars
These need not require a change in directory structure
/pom.xml (the super pom)
/jar-common-config/pom.xml (the jar common parent)
/war-common-config/pom.xml (the war common parent)
/jar-a/pom.xml
/jar-b/pom.xml
...
/war-a/pom.xml
/war-b/pom.xml
where /pom.xml has
...
jar-common-config
war-common-config
jar-a
jar-b
...
war-a
war-b
...
That will allow building all the modules from the root pom
/jar-a/pom.xml's parent would be jar-common-config with
../jar-common-config/pom.xml (although
I'm unsure if this is needed I think it's to do with release)
and
/war-a/pom.xml's parent would be war-common-config...
I prefer using the technique, but the separate
parents can work also.
-Stephen
On Nov 27, 2007 1:49 AM, Wayne Fay <[EMAIL PROTECTED]> wrote:
> Many plugins offer a configuration option. Check the plugin
> docs to see if jspc-m-p does, and if it does not, file a JIRA to
> request that someone else add it or do it yourself. Then you could
> simply add the plugin in the parent, and declare it with
> true in the non-WAR children projects.
>
> Wayne
>
>
> On 11/26/07, Amir Mistric <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I have a super-parent POM that all of my projects inherit...
> > 90% of the projects are WAR files and few are multi module JARs
> >
> > I would like to define a JSPC compile plugin at the super-parent POM level
> > but the problem arises when building non-WAR projects
> >
> > How can I "redefine" specific project's POMs (the ones that are JARs) not
> > to "consider" JSPC plugin?
> >
> >
> > The obvious solution is not to define jspc-maven-plugin at the super-parent
> > POM level but in each project individually...
> > But that means I have to specify something like this in multiple places
> > which I am trying to avoid:
> >
> >
> >org.codehaus.mojo.jspc
> >jspc-maven-plugin
> >2.0-alpha-1
> >
> >
> >
> > compile
> >
> >
> >
> >
> >
> >org.codehaus.mojo.jspc
> >jspc-compiler-tomcat5
> >2.0-alpha-1
> >
> >
> >
> >
> >${basedir}/src/main/resources/
> >
> > **/*.jsp
> >
> >
> > 1.6
> > 1.6
> > 1
> >
> >
> >
> >
> > Is there a way to do this? Currently I get following error when I try to
> > build one of my JAR projects:
> >
> > [WARNING] Compiled JSPs will not be added to the project and web.xml will
> > not be modified, either because includeInProject is set to false or because
> > the project's packaging is not 'war'.
> > [INFO] Created dir:
> > C:\mycompany\project\COOLP\mycompany-common\target\jsp-source
> > [INFO] Created dir:
> > C:\mycompany\project\COOLP\mycompany-common\target\classes
> > [INFO] Compiling JSP source files to
> > C:\mycompany\project\COOLP\mycompany-common\target/jsp-source
> > [INFO]
> >
> > [ERROR] FATAL ERROR
> > [INFO]
> >
> > [INFO] The -uriroot option must specify a pre-existing directory
> > [INFO]
> >
> > [INFO] Trace
> > org.apache.jasper.JasperException: The -uriroot option must specify a
> > pre-existing directory
> >
> >
>
> -
> 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]
problems mirroring repo1.maven.org
I'm getting the following errors while rsyncing repo1.maven.org Any idea how to fix these? rsync -v -t -l -r --exclude **/.svn/ --exclude .bak --exclude **/CVS/ mirrors.ibiblio.org::maven2 /var/www/repo1.maven.org - Welcome to the ibiblio.org mirrored software server! Note that the 'gnuwww' module was recently removed per discussion with the volunteers running gnu.org. Please go there if you wish to continue mirroring their web site. In its stead we are now offering the GNU Alpha archive. - receiving file list ... rsync: opendir "/ch/hortis/sonar/sonar-commons/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-commons/1.0.1" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-maven-plugin/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-maven-plugin/1.0.1" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar/1.0.1" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/db-maven-plugin/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/db-maven-plugin/1.0.1" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-application/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-application/1.0.1" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-core/1.0" (in maven2) failed: Permission denied (13) rsync: opendir "/ch/hortis/sonar/sonar-core/1.0.1" (in maven2) failed: Permission denied (13) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirecting build output to file
It would be great if it could be included in the release:perform goal... That way we could archive the build log of the artifact that was released... even better, deploy it once release:perform has completed the forked execution, that way the build log is available with the artifact. On Nov 28, 2007 12:20 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > If no user has ever asked for it (via JIRA), and no one in the dev > team has ever thought of it themselves, then the likelihood of it > landing in a release is extremely low. > > File a JIRA and perhaps it will be included in a future release. Since > you can simply pipe or tee the output, I'd expect the number of people > looking for something like this would be pretty low, but I could be > completely wrong... > > Wayne > > > On 11/28/07, Erez Nahir <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Scanning next releases plans, I could not find any jira issue asking for a > > flag to tell maven to print the output to a file. > > I might have missed it of course, but, if not is there a plan to support it? > > > > (I know I can redirect outpu using > or 'tee' but that's not what we > > are looking for. > > > > Thanks, > > Erez. > > > > - > 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: JUnit, NetBeans 6
have a look in target/surefire-reports/*.txt
On Nov 28, 2007 8:02 PM, Lally Singh <[EMAIL PROTECTED]> wrote:
> That fixes my pom problem, but it leaves me in the same state as
> before: no JUnit results. The JUnit integration doesn't work with an
> external maven.
>
> I just get a pass/fail result, but nothing to tell me why the test
> failed (e.g. stack traces).
>
> Is there a way to tell maven to give me more output about what failed
> in my tests?
>
>
> Thanks,
>
> -ls
>
> On 11/28/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
> > project.basedir might have been introduced after 2.0.4 (which is what the
> > embedded maven version is).
> > http://mevenide.codehaus.org/m2-site/faq.html#question4
> > or perhaps something to do with groovy plugin? not sure, never tried myself.
> > please try setting the project to use command line maven for building, that
> > should make the problem go away. Project/Properties to mark the project as
> > buildable by command line and Tools/Options for setting the path to maven
> > itself.
> >
> > If it's not working then, please file a bug report at
> > jira.codehaus.org/browse/MEVENIDE
> >
> > Milos
> >
> > On Nov 28, 2007 8:00 PM, Lally Singh <[EMAIL PROTECTED]> wrote:
> >
> > > I've got this little snippet in my POM:
> > >
> > >
> > > testdata_upload_vto
> > > test-compile
> > > operation
> > >
> > >CLEAN_INSERT
> > >${project.basedir}/src/test/data/db_vto.xml
> > >jdbc:mysql://testsql.iddl.vt.edu/vto
> > >
> > >
> > >
> > >
> > > I get this bit from running my tests in NB:
> > >
> > > [groovy:execute {execution: default}]
> > >
> > > [ERROR]BUILD ERROR
> > >
> > > src/test/data/db_vto.xml (No such file or directory)
> > >
> > > For more information, run Maven with the -e switch
> > >
> > > I change the file name to db_vtoF.xml in my POM, save the POM,
> > > reloaded the project, and hit test again. The error message referred
> > > to db_vto.xml, not db_vtoF.xml.
> > >
> > > Btw, the file's there, and this part of the test process runs fine
> > > from the command line. But in NB, the error shows up. When the right
> > > POM loads, I'll figure out what to put between those ${}.
> > >
> > > Thanks,
> > >
> > > -ls
> > >
> > >
> > > On 11/28/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
> > > > what do you mean by old version of POM? netbeans will update the project
> > > > definition if you changed the project's own pom, it will not currently
> > > do
> > > > automatically when changing something in the chain of parent poms. Use
> > > the
> > > > Reload action on project's popup. However for build execution there is
> > > no
> > > > caching, what is on disk is always used.
> > > >
> > > > are you using netbeans 5.5 or 6.0? if 6.0, are you using the maven
> > > support
> > > > from default update center? that one shall open the regular JUnit window
> > > if
> > > > you run the "Test project" action. If you use just Build/Rebuild, it
> > > shall
> > > > underline the errors in output and create a hyperlink to the
> > > stacktraces.
> > > >
> > > > Could be a bug.
> > > >
> > > > Milos
> > > >
> > > > On Nov 28, 2007 7:45 PM, Lally Singh <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > I've got a testcase that I'm trying to get working, but I've got a
> > > > > little dilemma:
> > > > >
> > > > > - In Netbeans, I can usually get a stacktrace for JUnit errors. But
> > > > > NB's using a bad (old?) version of my POM. E.g. I changed my pom and
> > > > > I continue to get an error mesage from the old version. NB's using
> > > > > some ancient version of my POM (probably from the initial project
> > > > > import), and I can't get it to use the new version.
> > > > >
> > > > > - Maven will (obviously) use the latest pom, but I don't know how to
> > > > > get any sort of failure report from my junit tests. Just a count & a
> > > > > list of the failed tests, but no stack traces or other diagnostics.
> > > > >
> > > > > Any idea how to fix either/both problems?
> > > > >
> > > > > Thanks in advance,
> > > > >
> > > > > -ls
> > > > >
> > > > > --
> > > > > H. Lally Singh
> > > > > Ph.D. Candidate, Computer Science
> > > > > Virginia Tech
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > H. Lally Singh
> > > Ph.D. Candidate, Computer Science
> > > Virginia Tech
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
> --
>
> H. Lally Singh
> Ph.D. Candidate, Compu
Re: obfuscation
We use JavaGuard with the following in the pom.xml
You could probably adapt it to your config
org.codehaus.mojo
exec-maven-plugin
package
java
JavaGuard
java
false
true
-i
${project.build.directory}/${project.build.finalName}.jar
-o
${project.build.directory}/${project.build.finalName}-obfuscated.jar
-s
${basedir}/src/main/obfuscate/config.properties
oro
oro
2.0.6
jar
net.sf.javaguard
javaguard
1.0beta4
jar
org.codehaus.mojo
build-helper-maven-plugin
package
attach-artifact
${project.build.directory}/${project.build.finalName}-obfuscated.jar
obfuscated
jar
On Nov 29, 2007 10:31 AM, ben short <[EMAIL PROTECTED]> wrote:
> Have a look at the antrun plugin [1]
>
> [1] http://maven.apache.org/plugins/maven-antrun-plugin/
>
> On Nov 29, 2007 10:29 AM, Richard Chamberlain
>
> <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> >
> >
> > I've got a requirement to obfuscate the java code we produce.
> >
> >
> >
> > Currently we use yguard with ant, there doesn't seem to be a maven
> > plugin for it :-( Does anyone use yguard with maven?
> >
> >
> >
> > So I was looking for a maven-friendly obfuscator. Does anyone use any
> > good ones?
> >
> >
> >
> > Cheers,
> >
> >
> >
> > Rich
> >
> >
> >
> > Richard Chamberlain
> > Software Engineer | Caplin Systems Ltd
> >
> > Office: +44 (0)20 7826 9639
> > Mobile: +44 (0)77 2068 6064
> > www.caplin.com
Re: problems mirroring repo1.maven.org
I thought it might have been my local permissions being incorrect... here's the latest set of errors. I'm going to try again against ibiblio (or do you recommend a better option: our proxy server is in germany) + rsync -v -t -l -r --exclude **/.svn/ --exclude .bak --exclude **/CVS/ rsync://rsync.cica.es/maven2 /var/www/repo1.maven.org receiving file list ... rsync: opendir "/org/objectweb/fractal/fscript" (in maven2) failed: Permission denied (13) done rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1-sources.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1-sources.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1-sources.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0.1/db-maven-plugin-1.0.1.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0-sources.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0-sources.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0-sources.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/db-maven-plugin/1.0/db-maven-plugin-1.0.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0-beta/sonar-application-1.0-beta.zip" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0-beta/sonar-application-1.0-beta.zip.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0-beta/sonar-application-1.0-beta.zip.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1-sources.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1-sources.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1-sources.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.zip" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-application/1.0.1/sonar-application-1.0.1.zip.md5" (in maven2): Permis
Re: problems mirroring repo1.maven.org
nar-maven-plugin/1.0/sonar-maven-plugin-1.0.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-maven-plugin/1.0/sonar-maven-plugin-1.0.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-maven-plugin/1.0/sonar-maven-plugin-1.0.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-maven-plugin/1.0/sonar-maven-plugin-1.0.pom.sha1" (in maven2): Permission denied (13) ch/hortis/sonar/sonar-maven-plugin/maven-metadata.xml ch/hortis/sonar/sonar-maven-plugin/maven-metadata.xml.md5 ch/hortis/sonar/sonar-maven-plugin/maven-metadata.xml.sha1 rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1-sources.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1-sources.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1-sources.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.war" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.war.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0.1/sonar-web-1.0.1.war.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0-sources.jar" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0-sources.jar.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0-sources.jar.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.war" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.war.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar-web/1.0/sonar-web-1.0.war.sha1" (in maven2): Permission denied (13) ch/hortis/sonar/sonar-web/maven-metadata.xml ch/hortis/sonar/sonar-web/maven-metadata.xml.md5 ch/hortis/sonar/sonar-web/maven-metadata.xml.sha1 rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0.1/sonar-1.0.1.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0.1/sonar-1.0.1.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0.1/sonar-1.0.1.pom.sha1" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0/sonar-1.0.pom" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0/sonar-1.0.pom.md5" (in maven2): Permission denied (13) rsync: send_files failed to open "/ch/hortis/sonar/sonar/1.0/sonar-1.0.pom.sha1" (in maven2): Permission denied (13) ch/hortis/sonar/sonar/maven-metadata.xml ch/hortis/sonar/sonar/maven-metadata.xml.md5 On Nov 28, 2007 11:47 AM, Carlos Sanchez <[EMAIL PROTECTED]> wrote: > fixed the permissions in the main repo, it will take some hours to propagate. > hortis.ch people need to fix the permissions on their side > > On Nov 28, 2007 7:29 PM, Stephen Connolly > > <[EMAIL PROTECTED]> wrote: > > I'm getting the following errors while rsyncing repo1.maven.org > > > > Any idea how to fix these? > > > > rsync -v -t -l -r --exclude **/.svn/ --exclude .bak --exclude **/CVS/ > > mirrors.ibiblio.org::maven2 /var/www/repo1.maven.org > > > > > > > > - > > > > Welcome to the ibiblio.org mirrored software server! >
Re: problems mirroring repo1.maven.org
Only this one is left with bad permissions: rsync: opendir "/org/objectweb/fractal/fscript" (in maven2) failed: Permission denied (13) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems mirroring repo1.maven.org
On Dec 1, 2007 7:28 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > Use a repository manager to only grab the dependencies you need in an on > demand fashion and cache them. This is much easier on the servers that > provide free access to the data. > If that is the policy change, can you see about updating http://maven.apache.org/guides/mini/guide-mirror-settings.html to reflect this. We have had issues with the proxy-cache technique and found an rsync updated once a day (we have no issues scaling back to once a week if traffic is a problem for people) to remove those issues (with developers wanting to try different versions and otherwise "play" with their prototypes prior to locking down. I'm hoping that Nexus will prove good enough that we could replace our mirroring, but I'm waiting for a version to be released. -Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to do incremental build?
On Dec 3, 2007 10:24 AM, Saloucious <[EMAIL PROTECTED]> wrote: > But it's not able to see affected files from modules which depend on > modified one, as Eclipse do. Eclipse gets this by scanning the java files to identify dependencies (for code complete, etc) and when it does it's background compilation. Essentially, Eclipse has done a lot of work in the background and built a dependency tree for each class. It would most likely take Maven just as long to figure out the dependencies as to do a clean compile unless maven were to persist the results of a dependency analysis into the target folder... Of course that would make the normal compiles slower... If you are running a CI server in the background (http://hudson.dev.java.net/ anyone?) then the compile time is less of an issue for Maven builds. If you are looking to take the changes quickly while developing, your IDE will have recompiled the necessary files anyway, so what is the problem with Maven's method of compiling only newer .java files... there should be none of them as your IDE will have compiled them, all you are using Maven for in that case is the packaging of artifacts (which your IDE will do for you anyway... and you're only doing a Maven build as a pre-test to commiting your changes... oh so in that case you _should_ be doing a clean install not an incremental) Just my €0.02 -Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to easily determine all the versions of plugins that are being used.
I remember seeing something (perhaps in a dream) about a nice easy way to get a list of all the versions of the plugins that are being resolved currently. I know the enforcer plugin has the ability (in theory) of locking down plugin versions. But given that the last released version of that plugin does not include the requirePluginVersions rule (as far as I can see... i.e. blows up every time!) I am at a loss as to how to easily lock down the plugin versions... Perhaps somebody could push a release of the enforcer plugin and the working version will produce a list like: the following versions are resolving but not specified. Or perhaps there's some magic plugin elsewhere that gives this info -Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-modules execution order
If M is the parent of A and B, then A and B both depend on M,
therefore M must be build first.
If A and B do not use M as their parent, then, AFAIK, A and B are
children so will be built first.
AFAIK, maven will try to build modules in the order they are declared,
unless dependencies override that, so if A depended on B then the
build order would be B A M... if B did not have M as a parent, A
depended on B and has M as a parent, I think the build order should be
B M A but could (at Maven's choice) be M B A.
Think of it as being just like the JVM between synchronization points.
As long as the outcome is the same, the JVM is free to reorder
operations as it sees fit even if this breaks what you intended...
(I may have got this example slightly wrong as every developer on
site is reading Java Concurrency in Practice and our copy currently is
at large!)
boolean flag = false;
Integer value = null;
Thread t = new Thread() {
public void run() {
if (flag) System.out.println(value.toString());
}
};
value = Integer.valueOf(5);
flag = true;
t.start()
Can validly print out:
* Nothing,
* NullPointerException
* 5
depending on the JVM and the machine you are running on. If this
scares you, read the excellent book Java Concurrency In Practice and
you'll realise everything you thought you knew about multi-threading
is wrong! (I know I did)
-Stephen
On Dec 11, 2007 9:12 AM, Jeff MAURY <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have the following problem:
> A multi module POM (called M) has tow modules A and B.
> If I run Maven on M, then the execution order is A,B and M.
>
> Now, let assume that M is the parent of A and B.
> The execution order is changed to M,A and B
> This causes me some trouble because I want to run plugins when M is builded
> that need to get stuff from A and B in the local repository.
> Another case is that you want to generated Javadoc with M and A or B cause
> generation of source files : if M is executed before A and B, then the
> Javadoc may be incomplete !!!
>
> Does everyone has experienced the same problem and is it a Maven bug or a
> Maven feature ?
>
> Thanks
> Jeff
>
>
> --
> La mélancolie c'est communiste
> Tout le monde y a droit de temps en temps
> La mélancolie n'est pas capitaliste
> C'est même gratuit pour les perdants
> La mélancolie c'est pacifiste
> On ne lui rentre jamais dedans
> La mélancolie oh tu sais ça existe
> Elle se prend même avec des gants
> La mélancolie c'est pour les syndicalistes
> Il faut juste sa carte de permanent
>
> Miossec (2006)
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: provided dep + tomcat:deploy + performRelease = "package XXX does not exist"
Provided means that it will be provided by the container (e.g. think Servlet API jar). Maven will provide it on the compile and test classpaths. You would not want the servlet API that you are using for compile time into the Tomcat classpath as tomcat is providing that dependency for you. There are all sorts of classloader issues that would arrise. What you need to do is to explicitly tell the tomcat-maven-plugin what dependencies in, addition to the standard dependencies, to make available to the tomcat conatiner it makes available to you. I'm not sure exactly how you do this with the tomcat plugin, but I would expect it to be by adding dependencies to the plugin configuration. On Dec 14, 2007 2:31 PM, Alexandre Gomes <[EMAIL PROTECTED]> wrote: > I'm not sure if I found a bug in tomcat-maven-plugin or if it's an expected > behaviour [1]. > > 1) Create a project with a "provided" scoped dependency [2] > 2) Try to execute tomcat:deploy with -DperformRelease=true [3] > 3) During the javadoc:jar phase, a warning is raised [4] > > [1] > > http://mojo.codehaus.org/tomcat-maven-plugin > > [2] > > >xstream >xstream >1.0.1 >provided >jar > > > [3] > > mvn tomcat:deploy > -Dmaven.tomcat.url=http://192.168.1.40:8080/manager-DperformRelease=true > > [4] > > [INFO] Javadoc Warnings > [WARNING] > /Users/alegomes/Documents/tmp/seaup.sea/src/main/java/br/com/seatecnologia/seaup/negocio/ConvertendoXML.java:5: > package com.thoughtworks.xstream does not exist > [WARNING] import com.thoughtworks.xstream.XStream; > [WARNING] ^ > [INFO] Building jar: /Users/alegomes/Documents/tmp/seaup.sea/target/seaup- > javadoc.jar > > > thanks > Alexandre Gomes > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filtering with Maven 2
look at in the maven-war-plugin configuration section
On Jan 4, 2008 1:26 PM, Dhruva Reddy <[EMAIL PROTECTED]> wrote:
> I am working with a Java web application and trying to filter resources
> for inclusion in the WAR file. This application runs in Tomcat.
>
> There is one file in particular, context.xml, which resides in
> src/main/webapp/META-INF/context.xml. I have the following in pom.xml:
>
>
> ...
>
>${user.home}/.m2/container.properties
>
>
>
> src/main/webapp
> true
>
>
> ...
>
> Without the above, the WAR contains META-INF/context.xml, as is necessary.
> However, when I have filtering turned on as above, I find the following in
> the WAR:
>
> META-INF/context.xml (this copy is not filtered)
> WEB-INF/classes/META-INF/context.xml (this copy is filtered as expected,
> but of course the file is in the wrong place)
>
> I am using Maven 2.0.8. Is it possible to filter this way, or is there
> something else I need to do for WAR files (like look at the WAR plugin)?
>
> Thanks,
> Dhruva
>
Re: how to set subversion authentication information into settings.xml (instead of writing it into project pom)
Of course when you use release:prepare release:perform it will publish your
username and password in the pom.xml that gets tagged
On Jan 8, 2008 10:11 AM, Boeckli, Dominique <[EMAIL PROTECTED]>
wrote:
> Hi Fred,
>
> i definded a profile in my personal settings.xml
>
>
>
>scmProfile
>
>userid
>password
>
>
>
>
>
>scmProfile
>
>
> And in the Super-POM (e.g. company POM) i defined the scm plugin like
> this:
>
>
>
>
>org.apache.maven.plugins
>
> maven-scm-plugin
>
>
> connection
>
> /checkout
>
> /checkout
>
> ${scm.username}
>
> ${scm.password}
>
>
>
>
> org.apache.maven.plugins
>
> maven-scm-plugin
>
>
> developerconnection
>
> /checkout
>
> /checkout
>
> ${scm.username}
>
> ${scm.password}
>
>
>
>
>
> I hope this was a help
>
> brgds
>
> Dominqiue
>
> -Original Message-
> From: Fred Zhang [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 14, 2007 10:11 AM
> To: Maven Users List
> Subject: how to set subversion authentication information into
> settings.xml (instead of writing it into project pom)
>
> Hi there,
> I'm working on configuring maven-scm plugin to use maven to do daily
> update/commit jobs.
>
> A problem is that I don't want to write my authentication information
> (username/password) into the project pom file (otherwise it will be
> shared through subversion). Neither want I use subversion "cached
> password" mechanism. I found some web-pages said that the svn repository
> server information (with username/password) could be written in
> settings.xml as following:
>
>
> http://svnrepo.my.com/svn/project/trunk
> username
> password
>
>
> And in project pom, just write
>
>
> scm:svn:http://svnrepo.my.com/svn/project/trunk
> http://svnrepo.my.com/svn/project/trunk
>
>
> Then the mvn scm:update should work.
>
> I tried. But I still got authentication failure.
>
> Is there any way to make it?
>
> Thanks in advance.
>
> Fred
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: can a plugin execute another one ?
I know that a plugin can fork a maven execution if it needs to... can't remember how On Jan 9, 2008 9:34 AM, nicolas de loof <[EMAIL PROTECTED]> wrote: > Hello, > > I need some custom packaging that requires to post-process the > tar.gzgenerated by the assembly plugin. > > How can I force the execution of the assembly plugin from another plugin ? > The @execute goal="" only applies on goals from the same plugin, and > assembly is not attached to a phase. > > Nico. >
Re: Maven Multimodule Site plugins
This is a known problem in maven. you need to run maven once (to build all the child reports) On the first run there are no child reports (because the parent is run first) Then you need to run maven a second time (to rebuild the parent report) The good news is that you need only run the parent module, e.g. mvn site mvn -N site should do the trick for you. You will have problems though if you have grandchildren modules, then you'll have the mvn site mvn site as the only way to get it to work. On Jan 9, 2008 10:34 PM, Morgovsky, Alexander (US - Glen Mills) < [EMAIL PROTECTED]> wrote: > Hello. Could someone please tell me if there are any multimodule site > reporting plugs which produce multimodule reports? I have tried many > plugins like javaNCSS but all the resulting sites return all 0's. > > > This message (including any attachments) contains confidential information > intended for a specific individual and purpose, and is protected by law. If > you are not the intended recipient, you should delete this message. > > > Any disclosure, copying, or distribution of this message, or the taking of > any action based on it, is strictly prohibited. [v.E.1] >
Re: Cobertura plugin
Danger! Will Robinson! Danger! How will you know that instrumenting your tests is not causing them to pass? Seriously, we had hand tweaked the pom to run the tests only once when they were instrumented, and as the instrumentation was forcing synchronisation (in order to track code path execution) it was eliminating a major concurrency bug that our unit tests were trying to prove was not there... IMHO, you _want_ to run the tests twice. -Stephen On Jan 10, 2008 12:26 PM, globulon <[EMAIL PROTECTED]> wrote: > > Houdy, > > I am newby to Maven 2. > > I have Introduced the Cobertura plugin in the reporting section of the > pom.xml file of my main project as follows: > > > ... > > > > >org.apache.maven.plugins > > maven-surefire-report-plugin > > > >org.codehaus.mojo > > cobertura-maven-plugin > > >html > > > > > > false > > > > > ... > > > It works fine. As I am also using the surefire reporting, it seems the > test > phase is run twice, one by > surefire and once by cobertura. > > Is there any way to instrument code before surefire execution for the two > plugin to share the same test sequence ? > > Thanx for your response ? > -- > View this message in context: > http://www.nabble.com/Cobertura-plugin-tp14731193s177p14731193.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: Cobertura
Use xml html The xml file is a standard cobertura xml report On Jan 11, 2008 8:43 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > Modify the Cobertura plugin so it does what you want. ;-) > > It is open source, after all. > http://mojo.codehaus.org/cobertura-maven-plugin/ > > Wayne > > On 1/11/08, Hilco Wijbenga <[EMAIL PROTECTED]> wrote: > > I'd like to do something like this: > > http://www.devx.com/Java/Article/36231 but not with Ant but with > > Maven. (In summary, it extracts the line coverage rate from the > > coverage.xml file created by Cobertura and uses it to make sure future > > builds can only do better, not worse.) > > > > The problem is that the Cobertura Maven plugin doesn't seem to make > > the resulting coverage percentage public. I can do a > > cobertura:dump-datafile but this doesn't output to a file. Besides > > there does not seem to be a way to tell the plugin to use any kind of > > configuration file. > > > > The only solution I can think of is to go the AntRun plugin route... > > Does anyone have a better idea? > > > > Cheers, > > Hilco > > > > - > > 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] > >
Strange problems with mvn release:perform when running javadoc:jar on Windows
On one of our developer's machines, they cannot do mvn javadoc:jar as it blows up due to an InvalidArrgumentException in (from memory) sun.net.www.ParserInfo.decode()! On other developer machines, there is no problem. The only difference we have found is the locale for this developer is English (Ireland) and the rest of us are English (UK) Windows XP. Sun JVM 1.5.0_14 & 1.6.0_01 & 1.6.0_04 all show the same issue. Maven 2.0.6 maven-javadoc-plugin 2.2 and 2.3 Has anybody seen this? Is there an issue raise, I could not see one Many thanks, -Stephen
Re: Strange problems with mvn release:perform when running javadoc:jar on Windows
javax.xml.parsers.FactoryFinder.findJarServiceProvider( FactoryFinder.java:250) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java :128) at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( LayoutParser.java:72) at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( ClassBuilder.java:108) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( HtmlDoclet.java:155) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles (AbstractDoclet.java:164) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( AbstractDoclet.java:106) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) com.sun.tools.doclets.internal.toolkit.util.DocletAbortException at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( LayoutParser.java:79) at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( ClassBuilder.java:108) at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( HtmlDoclet.java:155) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles (AbstractDoclet.java:164) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( AbstractDoclet.java:106) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) com.sun.tools.doclets.internal.toolkit.util.DocletAbortException at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( HtmlDoclet.java:159) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles (AbstractDoclet.java:164) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( AbstractDoclet.java:106) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) Command line was:C:\Java\jdk1.6.0_04\jre\..\bin\javadoc.exe -J-DproxyHost= nj.proxy.avaya.com -J-DproxyPort=8000 @options @packages at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport( AbstractJavadocMojo.java:1203) at org.apache.maven.plugin.javadoc.JavadocJar.execute(JavadocJar.java:108) ... 18 more [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Wed Jan 16 16:05:52 GMT 2008 [INFO] Final Memory: 5M/10M [INFO] On Jan 16, 2008 6:55 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > On one of our developer's machines, they
Re: unable to find mojo with hudson CI
Have you tried using the freestyle project type. If you can reproduce this issue using the freestyle project type, then it is probably a maven issue. If you cannot reproduce this issue using the freestyle project type, then it is most likely a problem with the way the m2 project type uses Maven Embedder, and you should file an issue at https://hudson.dev.java.net/ so that Kohsuke is aware of the problem. Also, the Hudson mailing list is probably a better place to have this discussion (unless you have this problem when using the freestyle project type) -Stephen On Jan 17, 2008 7:50 AM, globulon <[EMAIL PROTECTED]> wrote: > > Houdy, > > We are setting a CI environment using hudson as automata. We have created > a > task to execute our Mavan 2 project. > > Maven2 is launched using the parameters -Xmx1024 -Xms1024 > > goals are "clean install site-deploy" > > the maven-project-info-reports plugin canno't be found . We systematically > get > the following trace: > > - > this realm = > app0.child-container[org.apache.maven.plugins:maven-project-info- > reports-plugin] > urls[0] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/plugins/maven-project- > info-reports-plugin/2.0.1/maven-project-info-reports-plugin-2.0.1.jar > urls[1] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-provider- > clearcase/1.0-beta-3/maven-scm-provider-clearcase-1.0-beta-3.jar > urls[2] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/org/codehaus/plexus/plexus- > utils/1.1/plexus-utils-1.1.jar > urls[3] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-api/1.0- > beta-3/maven-scm-api-1.0-beta-3.jar > urls[4] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar > urls[5] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-provider- > svnexe/1.0-beta-3/maven-scm-provider-svnexe-1.0-beta-3.jar > urls[6] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-provider- > svn-commons/1.0-beta-3/maven-scm-provider-svn-commons-1.0-beta-3.jar > urls[7] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/regexp/regexp/1.3/regexp-1.3.jar > urls[8] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-manager- > plexus/1.0-beta-3/maven-scm-manager-plexus-1.0-beta-3.jar > urls[9] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/org/apache/maven/doxia/doxia-site- > renderer/1.0-alpha-8/doxia-site-renderer-1.0-alpha-8.jar > urls[10] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/doxia/doxia-core/1.0- > alpha-8/doxia-core-1.0-alpha-8.jar > urls[11] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar > urls[12] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta- > 6/plexus-i18n-1.0-beta-6.jar > urls[13] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/org/codehaus/plexus/plexus- > velocity/1.1.3/plexus-velocity-1.1.3.jar > urls[14] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/commons- > collections/commons-collections/2.0/commons-collections-2.0.jar > urls[15] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/velocity/velocity/1.4/velocity- > 1.4.jar > urls[16] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/velocity/velocity-dep/1.4/velocity-dep- > 1.4.jar > urls[17] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/doxia/doxia-decoration- > model/1.0-alpha-8/doxia-decoration-model-1.0-alpha-8.jar > urls[18] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/commons- > validator/commons-validator/1.2.0/commons-validator-1.2.0.jar > urls[19] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/commons- > beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar > urls[20] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/commons- > logging/commons-logging/1.0.4/commons-logging-1.0.4.jar > urls[21] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/commons- > digester/commons-digester/1.6/commons-digester-1.6.jar > urls[22] = file:/C:/Documents and > Settings/vastruc.STARS/.m2/repository/xml- > apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar > urls[23] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-provider- > cvsexe/1.0-beta-3/maven-scm-provider-cvsexe-1.0-beta-3.jar > urls[24] = file:/C:/Documents and > > Settings/vastruc.STARS/.m2/repository/org/apache/maven/scm/maven-scm-provider- > cvs-commons/1.0-beta-3/maven-scm-provider-cvs-commons-1.0-beta-3.jar > urls[25] = file:/C:/Documents and > > Settings/vastruc.S
Re: how filter not use some properities in pom.xml
I normally change how the resources folders are set up.
I have
src/
main/
java/
resources/
filtered/
verbatim/
test/
java/
resources/
filtered/
verbatim/
That way I have the resources with filtering in the filtered directory and
without in the verbatim directories. Makes life a lot easier. No messing
about with include/exclude rules, etc. And developers know if it's in
verbatim, it will be copied verbatim!
2008/1/17 Rex Huang <[EMAIL PROTECTED]>:
> Thanks Jeff, you method is sensible,
> but I am doing a migration project, I don't wanna to modify the file,
> because program may use it.
> So maven do not separate properties and filters, it may cause problem.
> I don't know whether other properties may affecting my files also.
>
> BR//Rex
>
>
> 2008/1/17 Jeff MAURY <[EMAIL PROTECTED]>:
>
> > Either you change the name of the property in your file or use the
> > properties tag in your pom but I'm afraid it will affect Maven.
> >
> > Jeff
> >
> >
> > 2008/1/17 Rex Huang <[EMAIL PROTECTED]>:
> >
> > > but I need to use filtering in other files with other properties,
> > > so filtering must be set to true, but is set by default, I
> don't
> > > want
> > > to use it as filter.
> > >
> > > BR//Rex
> > >
> > > 2008/1/17 Jeff MAURY <[EMAIL PROTECTED]>:
> > >
> > > > Change filtering from true to false.
> > > >
> > > > On Jan 17, 2008 12:03 PM, Rex Huang <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > by default in pom.xml there has properity
> > > > > such as:
> > > > >4.0.0
> > > > >com.mycompany.app
> > > > >my-app
> > > > >jar
> > > > >1.1-SNAPSHOT
> > > > >my-app
> > > > >
> > > > > and I use filtering like this:
> > > > >
> > > > >
> > > > >
> > > > >src/main/resources
> > > > >true
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > then files in src/main/resources has been replaced not as I
> wanted,
> > > such
> > > > > as
> > > > > in abc.txt:
> > > > > path=${name}.dat changed to path=my-app.dat
> > > > >
> > > > > actually I don't want it to be replaced, how can I do?
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > La mélancolie c'est communiste
> > > > Tout le monde y a droit de temps en temps
> > > > La mélancolie n'est pas capitaliste
> > > > C'est même gratuit pour les perdants
> > > > La mélancolie c'est pacifiste
> > > > On ne lui rentre jamais dedans
> > > > La mélancolie oh tu sais ça existe
> > > > Elle se prend même avec des gants
> > > > La mélancolie c'est pour les syndicalistes
> > > > Il faut juste sa carte de permanent
> > > >
> > > > Miossec (2006)
> > > >
> > > > http://www.jeffmaury.com
> > > > http://riadiscuss.jeffmaury.com
> > > >
> > >
> >
> >
> >
> > --
> > La mélancolie c'est communiste
> > Tout le monde y a droit de temps en temps
> > La mélancolie n'est pas capitaliste
> > C'est même gratuit pour les perdants
> > La mélancolie c'est pacifiste
> > On ne lui rentre jamais dedans
> > La mélancolie oh tu sais ça existe
> > Elle se prend même avec des gants
> > La mélancolie c'est pour les syndicalistes
> > Il faut juste sa carte de permanent
> >
> > Miossec (2006)
> >
> > http://www.jeffmaury.com
> > http://riadiscuss.jeffmaury.com
> >
>
Re: how filter not use some properities in pom.xml
The only bit I have not decided is how to handle webapps currently I end
up with
src/
main/
webapp/
filtered/
webapp/
but of course that breaks the rule.
I'd use the filtered for resources... but then where do the filtered test
resources go?!?
On Jan 17, 2008 9:25 PM, Stephen Connolly <[EMAIL PROTECTED]>
wrote:
> I normally change how the resources folders are set up.
>
> I have
>
> src/
> main/
> java/
> resources/
> filtered/
> verbatim/
> test/
> java/
> resources/
> filtered/
> verbatim/
>
> That way I have the resources with filtering in the filtered directory and
> without in the verbatim directories. Makes life a lot easier. No messing
> about with include/exclude rules, etc. And developers know if it's in
> verbatim, it will be copied verbatim!
>
>
> 2008/1/17 Rex Huang <[EMAIL PROTECTED]>:
>
> > Thanks Jeff, you method is sensible,
> > but I am doing a migration project, I don't wanna to modify the file,
> > because program may use it.
> > So maven do not separate properties and filters, it may cause problem.
> > I don't know whether other properties may affecting my files also.
> >
> > BR//Rex
> >
> >
> > 2008/1/17 Jeff MAURY <[EMAIL PROTECTED] >:
> >
> > > Either you change the name of the property in your file or use the
> > > properties tag in your pom but I'm afraid it will affect Maven.
> > >
> > > Jeff
> > >
> > >
> > > 2008/1/17 Rex Huang < [EMAIL PROTECTED]>:
> > >
> > > > but I need to use filtering in other files with other properties,
> > > > so filtering must be set to true, but is set by default, I
> > don't
> > > > want
> > > > to use it as filter.
> > > >
> > > > BR//Rex
> > > >
> > > > 2008/1/17 Jeff MAURY <[EMAIL PROTECTED]>:
> > > >
> > > > > Change filtering from true to false.
> > > > >
> > > > > On Jan 17, 2008 12:03 PM, Rex Huang <[EMAIL PROTECTED]>
> > wrote:
> > > > >
> > > > > > by default in pom.xml there has properity
> > > > > > such as:
> > > > > >4.0.0
> > > > > > com.mycompany.app
> > > > > >my-app
> > > > > >jar
> > > > > >1.1-SNAPSHOT
> > > > > >my-app
> > > > > >
> > > > > > and I use filtering like this:
> > > > > >
> > > > > >
> > > > > >
> > > > > >src/main/resources
> > > > > >true
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > then files in src/main/resources has been replaced not as I
> > wanted,
> > > > such
> > > > > > as
> > > > > > in abc.txt:
> > > > > > path=${name}.dat changed to path=my-app.dat
> > > > > >
> > > > > > actually I don't want it to be replaced, how can I do?
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > La mélancolie c'est communiste
> > > > > Tout le monde y a droit de temps en temps
> > > > > La mélancolie n'est pas capitaliste
> > > > > C'est même gratuit pour les perdants
> > > > > La mélancolie c'est pacifiste
> > > > > On ne lui rentre jamais dedans
> > > > > La mélancolie oh tu sais ça existe
> > > > > Elle se prend même avec des gants
> > > > > La mélancolie c'est pour les syndicalistes
> > > > > Il faut juste sa carte de permanent
> > > > >
> > > > > Miossec (2006)
> > > > >
> > > > > http://www.jeffmaury.com
> > > > > http://riadiscuss.jeffmaury.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > La mélancolie c'est communiste
> > > Tout le monde y a droit de temps en temps
> > > La mélancolie n'est pas capitaliste
> > > C'est même gratuit pour les perdants
> > > La mélancolie c'est pacifiste
> > > On ne lui rentre jamais dedans
> > > La mélancolie oh tu sais ça existe
> > > Elle se prend même avec des gants
> > > La mélancolie c'est pour les syndicalistes
> > > Il faut juste sa carte de permanent
> > >
> > > Miossec (2006)
> > >
> > > http://www.jeffmaury.com
> > > http://riadiscuss.jeffmaury.com
> > >
> >
>
>
Re: Strange problems with mvn release:perform when running javadoc:jar on Windows
Anyone??? or will i just file an issue On Jan 17, 2008 8:24 AM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > Here is the stacktrace: > > The exact same commands from my machine work with the exact same proxyHost > and proxyPort and JDK and Maven version > > [INFO] [javadoc:jar] > [DEBUG] C:\Java\jdk1.6.0_04\jre\..\bin\javadoc.exe > -J-DproxyHost=.com -J-DproxyPort= @options @packages > Loading source files for package com.... > Constructing Javadoc information... > Standard Doclet version 1.6.0_04 > Building tree for all the packages and classes... > Generating > C:/work/jsr-112-workmanager-impl/target/apidocs\com/___/___/___//\_.html... > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error while creating archive:Exit code: 1 - > java.lang.IllegalArgumentException > at sun.net.www.ParseUtil.decode(ParseUtil.java:189) > at sun.misc.URLClassPath$FileLoader.(URLClassPath.java:953) > at sun.misc.URLClassPath$3.run(URLClassPath.java:326) > at java.security.AccessController.doPrivileged(Native Method) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) > at sun.misc.URLClassPath.findResource(URLClassPath.java:144) > at java.net.URLClassLoader$2.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findResource(URLClassLoader.java:359) > at java.lang.ClassLoader.getResource(ClassLoader.java:977) > at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1159) > at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96) > at java.security.AccessController.doPrivileged(Native Method) > at javax.xml.parsers.SecuritySupport.getResourceAsStream( > SecuritySupport.java:89) > at javax.xml.parsers.FactoryFinder.findJarServiceProvider( > FactoryFinder.java:250) > at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) > at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java > :128) > at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( > LayoutParser.java:72) > at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( > ClassBuilder.java:108) > at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( > HtmlDoclet.java:155) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles( > AbstractDoclet.java:164) > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( > AbstractDoclet.java:106) > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( > AbstractDoclet.java:64) > at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java > :42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) > com.sun.tools.doclets.internal.toolkit.util.DocletAbortException > at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( > LayoutParser.java:79) > at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( > ClassBuilder.java:108) > at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( > HtmlDoclet.java:155) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles( > AbstractDoclet.java:164) > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( > AbstractDoclet.java:106) > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( > AbstractDoclet.java:64) > at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java > :42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.inv
Re: Strange problems with mvn release:perform when running javadoc:jar on Windows
oh it gets stranger. we have no problems with javadoc:javadoc, only javadoc:jar On Jan 18, 2008 9:57 AM, Tom Huybrechts <[EMAIL PROTECTED]> wrote: > I've had my share of javadoc problems, but not this one. Did you try to > run > the javadoc command itself from the commandline ? > > Tom > > On Jan 18, 2008 10:48 AM, Stephen Connolly < > [EMAIL PROTECTED]> > wrote: > > > Anyone??? or will i just file an issue > > > > On Jan 17, 2008 8:24 AM, Stephen Connolly < > [EMAIL PROTECTED] > > > > > wrote: > > > > > Here is the stacktrace: > > > > > > The exact same commands from my machine work with the exact same > > proxyHost > > > and proxyPort and JDK and Maven version > > > > > > [INFO] [javadoc:jar] > > > [DEBUG] C:\Java\jdk1.6.0_04\jre\..\bin\javadoc.exe > > > -J-DproxyHost=.com -J-DproxyPort= @options @packages > > > Loading source files for package com.... > > > Constructing Javadoc information... > > > Standard Doclet version 1.6.0_04 > > > Building tree for all the packages and classes... > > > Generating > > > > > > C:/work/jsr-112-workmanager-impl/target/apidocs\com/___/___/___//\_.html... > > > [INFO] > > > > > > > [ERROR] BUILD ERROR > > > [INFO] > > > > > > > [INFO] Error while creating archive:Exit code: 1 - > > > java.lang.IllegalArgumentException > > > at sun.net.www.ParseUtil.decode(ParseUtil.java:189) > > > at sun.misc.URLClassPath$FileLoader.(URLClassPath.java:953) > > > at sun.misc.URLClassPath$3.run(URLClassPath.java:326) > > > at java.security.AccessController.doPrivileged(Native Method) > > > at sun.misc.URLClassPath.getLoader(URLClassPath.java:320) > > > at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) > > > at sun.misc.URLClassPath.findResource(URLClassPath.java:144) > > > at java.net.URLClassLoader$2.run(URLClassLoader.java:362) > > > at java.security.AccessController.doPrivileged(Native Method) > > > at java.net.URLClassLoader.findResource(URLClassLoader.java:359) > > > at java.lang.ClassLoader.getResource(ClassLoader.java:977) > > > at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1159) > > > at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96) > > > at java.security.AccessController.doPrivileged(Native Method) > > > at javax.xml.parsers.SecuritySupport.getResourceAsStream( > > > SecuritySupport.java:89) > > > at javax.xml.parsers.FactoryFinder.findJarServiceProvider( > > > FactoryFinder.java:250) > > > at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) > > > at javax.xml.parsers.SAXParserFactory.newInstance( > SAXParserFactory.java > > > :128) > > > at > > com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML( > > > LayoutParser.java:72) > > > at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build > ( > > > ClassBuilder.java:108) > > > at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles( > > > HtmlDoclet.java:155) > > > at > > > > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles > > ( > > > AbstractDoclet.java:164) > > > at > > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration( > > > AbstractDoclet.java:106) > > > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( > > > AbstractDoclet.java:64) > > > at com.sun.tools.doclets.formats.html.HtmlDoclet.start( > HtmlDoclet.java > > > :42) > > > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > at sun.reflect.NativeMethodAccessorImpl.invoke( > > > NativeMethodAccessorImpl.java:39) > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > > > DelegatingMethodAccessorImpl.java:25) > > > at java.lang.reflect.Method.invoke(Method.java:597) > > > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) > > > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) > > > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > > > at com.sun.tools.javadoc.Start.begin(Start.java:128) > >
Re: how to manually change a jar from SNAPSHOT to release?
There are two ways: 1. Give it a new version number (e.g. 2.0-yourcompany-1) because you may want to re-build it if/WHEN you find issues with your build, and if you don't attach a build/version to the version number you'll be in trouble. Also you should prefix the build/version with yourcompany so people know it's you as what did it. 2. Alternatively, change the groupId to com.yourcompany.yourproduct... now you can have any version number you like. For that kind of change I would strongly recommend importing the source code into your SCM, as in reality this is a "fork" For both 1 & 2 I would ensure that you have a snapshot of the source code in SCM, but with option 2, you really will need that snapshot. Also #2 is probably better suited to when you need to patch the source heavily in order to get it to build, whereas #1 is for when they just have not pushed a release as recently as you'd like. Just my €0.02 On Jan 22, 2008 7:54 PM, Ken Liu <[EMAIL PROTECTED]> wrote: > Hi all - > > I am getting close to releasing a project and am trying to nail down all > the > SNAPSHOT dependencies. I have one plugin (jboss-sar), which was never > released, and only has a 2.0-SNAPSHOT version available. I want to take > this jar and assign a release number to it to be installed in our internal > maven repo. > > Is there an "official" way to do this? I have been manually doing the > following: > 1) in the jar, editing plugin.xml and replacing the version "2.0-SNAPSHOT" > with "2.0-MINE" > 2) in the jar, editing pom.properties and changing the property " > 2.0-SNAPSHOT" with "2.0-MINE" > 3) in the jar, editing pom.xml and replacing the version "2.0-SNAPSHOT" > with > "2.0-MINE" > 4) renaming the jar from "jboss-sar-maven-plugin-2.0-SNAPSHOT.jar" to " > jboss-sar-maven-plugin-2.0-MINE.jar" > 5) using "mvn install:install-file" to add the jar to my internal > repository > > Is this sufficient? Did I miss any steps? Is there an easier way to do > this? >
Re: Any tool available for generating docs from pom.xml?
The site plugin's info reports? On Jan 23, 2008 7:58 AM, amit kumar <[EMAIL PROTECTED]> wrote: > Hi, > I know this would sound stupid ( as it sounded to me when asked ), but > is there any such tool using which you can generate a doc in tabular > format with the information stored in pom.xml mainly the dependency > part. > > Please let me know in case there exists one tool. > > Regards, > Amit > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: JUnit tests requiring j2ee.jar fail when running mvn surefire:test
Don't use the borked j2ee.jar from the java.net or java.net2 maven repositories. I had the same problem. Basically, the j2ee.jar on the java.net repos is not a real jar, just stripped classes that have no method bodies, but just the method definitions. The borked jar is only good for compiling. I had an argument with the guy who posted it where I pointed out "why-the-f*ck-would-you-want-a-jar-that-you-cannot-run-unit-tests-against-in-a-maven-repository" and he seemed to think that not running unit tests was a perfectly valid use case and sure nobody using maven runs unit tests all the time, and sure could they not just compile and package the jar... He did not seem to get the whole lifecycle thing about maven2 at all On Jan 23, 2008 11:27 PM, Derry Cannon <[EMAIL PROTECTED]> wrote: > Hey, there! > > I've got a JUnit 4.2 test that tests a simple little email address > validator. The validator uses javax.mail.internet.InternetAddress. > Everything works fine in Eclipse when I run it as a JUnit Test. However, > when I try to install the project containing the JUnit test, it fails on > the > surefire:test with the following: > > java.lang.ClassFormatError: Absent Code attribute in method that is not > native or abstract in class file javax/mail/internet/AddressException. > > Can anyone suggest what to do differently to make the JUnit test run > properly during the surefire:test? > > Thanks much! > Derry >
Re: JUnit tests requiring j2ee.jar fail when running mvn surefire:test
By the way, the individual component jars that go to make up j2ee.jar are fine, so all you need to do is figure out which parts of the j2ee spec you need and include the relevant artifact, i.e. mail, servlet, ejb, etc On Jan 24, 2008 8:59 AM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > Don't use the borked j2ee.jar from the java.net or java.net2 maven > repositories. > > I had the same problem. Basically, the j2ee.jar on the java.net repos is > not a real jar, just stripped classes that have no method bodies, but just > the method definitions. > > The borked jar is only good for compiling. I had an argument with the guy > who posted it where I pointed out > "why-the-f*ck-would-you-want-a-jar-that-you-cannot-run-unit-tests-against-in-a-maven-repository" > and he seemed to think that not running unit tests was a perfectly valid use > case and sure nobody using maven runs unit tests all the time, and sure > could they not just compile and package the jar... > > He did not seem to get the whole lifecycle thing about maven2 at all > > > On Jan 23, 2008 11:27 PM, Derry Cannon <[EMAIL PROTECTED]> wrote: > > > Hey, there! > > > > I've got a JUnit 4.2 test that tests a simple little email address > > validator. The validator uses javax.mail.internet.InternetAddress. > > Everything works fine in Eclipse when I run it as a JUnit Test. > > However, > > when I try to install the project containing the JUnit test, it fails on > > the > > surefire:test with the following: > > > > java.lang.ClassFormatError: Absent Code attribute in method that is not > > native or abstract in class file javax/mail/internet/AddressException. > > > > Can anyone suggest what to do differently to make the JUnit test run > > properly during the surefire:test? > > > > Thanks much! > > Derry > > > >
Re: Profile activation by time range?
Use two hudson jobs. Oh and _please_ file an issue with hudson.dev.java.netto get the batch-tasks plugin to work with m2 project types! On Jan 24, 2008 2:37 AM, Paul Benedict <[EMAIL PROTECTED]> wrote: > I believe you can write your own profile activation class, but that's a > feature of Maven 2.1 > > Paul > > On Jan 23, 2008 7:43 PM, Ravi Luthra <[EMAIL PROTECTED]> wrote: > > > Does anyone know how to activate a profile in maven if the time is > > between a certain hour of the day? > > > > I'm using a CI to build during every checkin, which also deploys the > > code. However the build server does the entire site generation and has > > about 10 plugins connected to it, This makes our builds very slow on > > the server. What I want to do is only do the site build at midnight. > > The only problem is our CI server (hudson) doesn't let you specify > > different run options for different times of the day. (at least when > > using Maven integration mode). > > > > What I want to do is have Maven activate the profile based on the time > > of day, so that Hudson doesn't have to know about it. I had a bunch of > > thoughts on this: > > 1) Create a separate process that drops a file onto the system only > > between 11:50pm and 12:10am. Have the profile containing the site > > plugin configuration activate based on this file existing. > > 2) OR I could create a maven plugin that runs first, and if it is > > between a certain time range, activate other profiles during that same > > build. (not sure how to do this) > > 3) Request an enhancement to Maven devs to support time based profile > > activation. > > > > Any of these feasible? > > > > Thanks, > > Ravi > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: Clearcase Snapshot View Synchronisation
Be careful to remember that to use Hudson effectively, you'll probably want
to throw away a lot of the cruddy workarounds that are likely in your build
script.
For example, we used to have one build script check out from source control
because CruiseControl would not always get things correct (i.e. it became a
fancy cron)
Another build script would do a lot of reporting against the SCM and parsing
of unit test results (because we did not have those reports automatically
from hudson)
On Jan 24, 2008 7:27 AM, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
> Hudson is a lot easier to use then Cruise Control (I have not used Cruise
> Control, but other people have told me that). It has a ClearCase plugin (I
> use it also) so definitely worth a try.
>
> regards,
>
> Wim
>
> 2008/1/23, Richard M Smith <[EMAIL PROTECTED]>:
> >
> > Thanks for replying Wim,
> >
> > We do have our own custom build using Cruise Control which I'm
> converting
> > to use ClearCase instead of SourceSafe. I've not seen Hudson but I'll
> > check
> > it out. It seems we already have scm:update as part of the goal so maybe
> > something else is wrong, or the scm:update doesn't do quite what I want
> it
> > to, or maybe I haven't get ClearCase set up properly. Here's some of the
> > config.xml code...
> >
> >> classname="net.sourceforge.cruisecontrol.ProjectConfig"
> > buildafterfailed="false">
> >
> >
> >
> >> viewPath="${pdir}\${parent.name}\packages\${package.name}" file="pom.xml
> "
> > />
> > > viewPath="${pdir}\${parent.name}\packages\${package.name}"
> > file="\assemble-bin.xm" />
> > > file="pom.xml" />
> > > file="settings.xml" />
> >
> >
> >
> >
> >
> >
> >> pomfile="${pdir}/${parent.name}/packages/${package.name}/pom.xml"
> > mvnscript="${pdirmaven}/cruisecontrol2/${mvn_script}"/>
> >
> > .
> >
> >
> >
> >
> >
> >
> >
> > I did wonder about calling cleartool in the batch file ...?
> >
> > Thanks
> >
> > Richard
> >
> >
> >
> >
> >
> > [EMAIL PROTECTED]
> > l.comTo:
> > users@maven.apache.org
> >cc:
> > 23/01/2008 15:28 Subject: Re: Clearcase
> > Snapshot View Synchronisation
> > Please respond to
> > users
> >
> >
> >
> >
> >
> >
> > Do you have an own build system? Maybe you are better of using something
> > like Hudson?
> >
> > The command to update the view is scm:update (
> > http://maven.apache.org/scm/plugins/index.html#update-mojo)
> >
> > regards,
> >
> > Wim
> >
> > 2008/1/22, Richard M Smith <[EMAIL PROTECTED]>:
> > >
> > >
> > > Can anyone supply some sample code for automatically synchronising a
> > > Clearcase snapshot view prior to a build?
> > >
> > > I am in the process of switching my Maven 2 Java build from Visual
> > Source
> > > Safe to ClearCase (new to me).
> > >
> > >
> > > maven-scm-plugin
> > >
> > > scm:clearcase:view:load
> > >
> > >
> >
> >
> /NESS_PVOB1/Projects/NESS_FR01/NESS_FR01_Int:NESS_PVOB1:xrender_dev
> >
> > > true
> > > model/**
> > >
> > >
> > >
> > > This works but I currently need to go into Clearcase and manually
> > > resynchronise the view to pick up changes. I would like the build to
> do
> > it
> > > for me. I have been supplied with some Ant code...
> > >
> > >> > outputproperty="checked.stream.response">
> > >
> > >
> > >
> > >
> > > I want to do something similar in Maven but I can't find an example.
> > > Nearest I could get was a bug report saying cleartool update -force
> > could
> > > cause a crash.
> > >
> > > Thanks
> > >
> > > Richard
> > >
> >
> >
> >
> >
> >
> > For the latest data on the economy and society consult National
> Statistics
> > at http://www.statistics.gov.uk
> >
> >
> >
> *
> >
> >
> > Please Note: Incoming and outgoing email messages are routinely
> monitored
> > for compliance with our policy on the use of electronic communications
> >
> >
> *
> >
> >
> > Legal Disclaimer : Any views expressed by the sender of this message
> are
> > not necessarily those of the Office for National Statistics
> >
> >
> *
> >
> >
> > The original of this email was scanned for viruses by the Government
> > Secure Intranet virus scanning service supplied by Cable&Wireless in
> > partnership with MessageLabs. (CCTM Certificate Number 2007/11/0032.) On
> > leaving the GSi this email was certified virus free.
> > Communications via the GSi may be automatically logged, monitored and/or
> > recorded for
Re: how to manually change a jar from SNAPSHOT to release?
Yes. The maven metadata .xml files They contain information about what the RELEASE version is and so on. If you don't update these files correctly, strange things will happen when maven is pulling the files down from the remote repository. Similar will happen if you try to copy a file into your local repository directly. Never put files into the local or remote repository directly, only ever use install:install-file or deploy:deploy-file as these maintain the metatdata files for you. (At least that is what I was told) On Jan 24, 2008 2:52 PM, Ken Liu <[EMAIL PROTECTED]> wrote: > Hi Stephen - > > I don't understand what you are saying. Can you explain in more detail? > > My shared repository is no different than a local workstation repository > (just a bunch of files in a directory tree). If I ftp the artifact and the > POM to the server and run install:file, won't the artifact resolve > properly? Is there something I am missing? > > Ken > > On 1/23/08, Stephen Connolly <[EMAIL PROTECTED]> wrote: > > > > you should never just FTP or copy the file. deploy:deploy-file will > > update the metadata. things will go very bad if you don't update the > > metadata > > > > Sent from my iPod > > > > On 23 Jan 2008, at 21:43, "Ken Liu" <[EMAIL PROTECTED]> wrote: > > > > > > > > Thanks, I'm going with #1. The source svn repo seems to have gone away > > (actually I probably can dig around in their svn history to find it, but > > don't have the time/motivation). > > > > Can I use deploy:deploy-file the same ways as install:install-file? I > > usually just ftp the files to the shared maven repo and then telnet in to > > run install. I briefly looked at the deploy plugin docs, but it looked > > really complicated. > > > > Ken > > > > > > On 1/22/08, Stephen Connolly < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > wrote: > > > > > > Well if you are just repackaging the -SNAPSHOT jar, then you don't > > > need to build from source... > > > > > > I'd look at deploy:deploy-file rather than install:install-file as > > > otherwise how will the other developers on your team get the artifact (of > > > course you'd need to have your own repo to deploy to in such a case). > > > > > > Building from source (if it's a maven project) might actually be > > > easier: > > > > > > 1. pull the source from SCM > > > 2. Import the source to your SCM > > > 3. update the tag in the pom.xml > > > 4. release:prepare release:perform > > > > > > presto-chango, you're done > > > > > > On Jan 22, 2008 8:59 PM, Ken Liu < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > > wrote: > > > > > > > Hi Stephen - > > > > > > > > Thanks for your reply. Those euro-cents are worth a a lot more than > > > > my $.02. > > > > > > > > I'm leaning toward option #1. > > > > > > > > To clarify, I wasn't planning on rebuilding the jar from the source, > > > > just taking the SNAPSHOT jar from the public repo. In fact, I don't > > > > intend > > > > to ever have to do this again because the particular plugin is no longer > > > > under development (there was never an official, non SNAPSHOT release). > > > > But > > > > point taken, if we were using a different SNAPSHOT plugin, then we might > > > > want to version a newer SNAPSHOT. I plan on using the version " > > > > 2.0-mycompany-1". > > > > > > > > Are the steps that I described sufficient for changing the version > > > > number in the jar, or is it really necessary to build from the source? > > > > I > > > > would rather not spend time/effort rebuilding something from the source > > > > when > > > > the artifact is already being used. > > > > > > > > Ken > > > > > > > > On 1/22/08, Stephen Connolly < <[EMAIL PROTECTED]>[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > There are two ways: > > > > > > > > > > 1. Give it a new version number (e.g. 2.0-yourcompany-1) because > > > > > you may > > > > > want to re-build it if/WHEN you find issues with your build, and > > > > > if you > > > > > don't attach a build/version to the version num
Re: [ANN] Maven Dependency Plugin 2.0 Released
I'd love if there was a dependency:list-plugins though (that showed the plugin versions) On Jan 28, 2008 9:42 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Many thanks. > > I think dependency:tree is possibly the best feature since maven 2.0.0. > > Erez Nahir <[EMAIL PROTECTED]> schrieb: > > Cograts !! that is great. > > > > Erez. > > > > On Jan 28, 2008 10:56 AM, Kalle Korhonen <[EMAIL PROTECTED]> > wrote: > > > > > Congrats and big thanks! I'm sure there's been a lot of people waiting > for > > > this plugin release, especially those interested in the dashboard, me > > > included. > > > > > > Kalle > > > > > > > > > On 1/25/08, Brian Fox <[EMAIL PROTECTED]> wrote: > > > > > > > > The Maven team is pleased to announce the 2.0 release of the Maven > > > > Dependency Plugin: > > > > > > > > http://maven.apache.org/plugins/maven-dependency-plugin > > > > > > > > This release fixes many issues and introduces several new goals for > > > > dependency analysis and output. > > > > > > > > Release Notes - Maven 2.x Dependency Plugin - Version 2.0 > > > > > > > > > > > > ** Bug > > > > * [MDEP-59] - dependency:unpack can't extract rar archives > > > > * [MDEP-74] - dependencies in test scope are not handled > properly by > > > > analyze > > > > * [MDEP-75] - non-portable classpath separator in > build-classpath > > > > output > > > > * [MDEP-80] - Usage page of the docs use an overWrite property, > > > > but none exists in the (auto-generated) goal reference docs > > > > * [MDEP-81] - analyzer can't handle non-pom projects that don't > > > > produce a /target folder > > > > * [MDEP-83] - Typo in "How to prepare your dependencies before > > > > updating to Maven 2.0.6" > > > > * [MDEP-91] - org.codehaus.mojo:dependency-maven-plugin takes > > > > precedence over org.apache.maven.plugins:maven-dependency-plugin > > > > * [MDEP-93] - Tests can fail with OOME > > > > * [MDEP-95] - can't build unit tests with jdk1.4 rev 545703 > > > > * [MDEP-97] - dependency:tree not consistent with maven core's > > > > dependency tree > > > > * [MDEP-113] - Unable to find the mojo > > > > 'org.apache.maven.plugins:maven-site-plugin:2.0-SNAPSHOT > > > > * [MDEP-120] - build-classpath is unable to build a classpath > with > > > > runtime or test dependencies > > > > > > > > ** Improvement > > > > * [MDEP-89] - change separators in build-classpath > > > > * [MDEP-96] - Allow includes and excludes to be used > > > > simultaneously in the same filter > > > > * [MDEP-99] - Unpack SWC files > > > > * [MDEP-100] - Merge dependency:tree branch for new features > > > > * [MDEP-101] - Add dependency:list alias for dependency:resolve > > > > * [MDEP-104] - Add Analyze HTML Report > > > > * [MDEP-111] - Provide output on file as in other goals > > > > * [MDEP-119] - build-classpath should create destination > directory > > > > for the classpath file > > > > * [MDEP-125] - Build-classpath should store the classpath in a > > > Filter > > > > * [MDEP-129] - allow substitution of the absolute local repo > path > > > > with a property > > > > * [MDEP-130] - allow the classpath file to be attached > > > > * [MDEP-131] - Complete i18n support for new analyze-report > > > > * [MDEP-132] - Add german translation for analyze-report mojo > > > > * [MDEP-133] - Add dedicated resource bundle for locale "en" > > > > > > > > ** New Feature > > > > * [MDEP-47] - Ability to have an includes/excludes feature on > the > > > > dependency:unpack goal. > > > > * [MDEP-70] - add new mojo to perform analysis of dependencies > and > > > > fail the build if certain conditions aren't met > > > > * [MDEP-71] - add report to display contents of > dependency-analyzer > > > > * [MDEP-94] - Add dependency:tree goal > > > > * [MDEP-116] - [dependency :copy-dependencies ] Add parameter to > > > > allow extracting POMs > > > > > > > > > - > > > > 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: Parent project version
AFAIR
property expansion is not performed in the parent tag... or maybe it's just
the version tag of the parent tag...
The logic is that it's not reproducible.
In my view this is the weakest link in Maven 2 as you then need to use the
release plugin to update all the child projects... makes changing the parent
a pain... which leads to people who don't understand about deploy being
essentially write-once trying to hack and modify the parent and "re-deploy"
it.
I'm not sure that I can see a better way though... unless 2.1 introduced the
concept of a tightly coupled child, i.e. if
../pom.xml
would just read the parent direct from the relative path. At deployment
time the parent details can be populated, but developers would not have to
worry while developing
-Stephen
On Jan 29, 2008 9:01 PM, Mick Knutson <[EMAIL PROTECTED]> wrote:
> That did not work on the parent:
>
>org.delta.esp.dap.eep
>common
>*${project.version}*
>../pom.xml
>
>
>
> Still gives errors saying:
>
> *Reason: Unable to download the artifact from any repository
>
> org.delta.esp.dap.eep:common:pom:${project.version}
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)*
>
>
>
>
> On Jan 29, 2008 12:28 PM, Rune Flobakk <[EMAIL PROTECTED]> wrote:
>
> > We're doing just that on the project I am working on; no version
> > specified in the child POMs, and it gets inherited from the parent POM.
> >
> > So since the child modules get the version implicitly, it should work
> > just referring to ${project.version}? (haven't tried it myself)
> >
> > -Rune
> >
> > Erez Nahir wrote:
> > > IMHO it should even be easier, just remove the tag from the
> > child
> > > poms.
> > > It will inherit the version from the parent.
> > >
> > > Erez.
> > >
> > > On Jan 29, 2008 9:52 PM, Manos Batsis <[EMAIL PROTECTED]>
> > wrote:
> > >
> > >> I never actually managed to do that. IMHO that should be as easy as
> > >>
> > >> ${project.parent.version}
> > >>
> > >> Oh well :-)
> > >>
> > >> Cheers,
> > >>
> > >> Manos
> > >>
> > >> Mick Knutson wrote:
> > >>> I am actually trying to use a property:
> > >>>
> > >>> 1.0.2
> > >>>
> > >>> Then use that property in my child pom's:
> > >>>
> > >>> ${org.delta.esp.dap.version}
> > >>>
> > >>> When I do an install and deploy it seems to work, but when I am
> doing
> > a
> > >>> site-deploy, the parameter is not found and I get errors.
> > >>>
> > >>> Is there a better way?
> > >>>
> > >>>
> > >>>
> > >>> On Jan 29, 2008 10:23 AM, Arthur Rodrigues Stilben <
> > >>> [EMAIL PROTECTED]> wrote:
> > >>>
> > Is there a way to use the version of a parent project in its
> > childrens
> > projects?
> >
> > Arthur Rodrigues Stilben
> >
> >
> -
> > 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]
> >
> >
>
>
> --
> Thanks,
> Mick Knutson
>
> http://www.baselogic.com
> http://www.blincmagazine.com
> http://www.djmick.com
> http://www.myspace.com/mickknutson
> http://www.myspace.com/BLiNCMagazine
> http://tahoe.baselogic.com
> ---
>
Re: Parent project version
Yep! which was why I had only which would force you to check out the parent. i.e. it would be a child that _cannot_ be build without the parent, for use by developers the release plugin would (on the version tagged for release) replace the tag with the released parent's identification triplet (or quartet if you're mad and have a classifier too) so that releasing the parent will give a stand-alone module that can build on it's own, but the trunk poms would not change On Jan 30, 2008 9:19 AM, Heinrich Nirschl <[EMAIL PROTECTED]> wrote: > On Jan 30, 2008 8:59 AM, Erez Nahir <[EMAIL PROTECTED]> wrote: > > I also think as Stephen, > > > > Having an option to specify parent with relative path will be very > helpfull, > > I'm sure a solution can be found to provide this functionality. > > Maybe something like having both and and give > > precedence to such that if it is found, it will be used > and > > if not, the will be used instead... > > > > Erez. > > This would give different results when the whole tree is checked out > vs. just the module is checked out. > > - Henry > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: maven renaming jar files
Or if you are checking them in manually, at least use a different version which includes your company name, e.g. commons-logging commins-logging 1.0-mycompany-1 That way maven will at least detect that these are different versions of the same artifact and the version ranges and preferences should* let you pick your one! -Stephen * Yes I know some people have issues with version ranges, etc. but there are ways of making them work, or at least using a dependencyManagement section On Jan 31, 2008 4:07 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > We've had more than one person show up on this list complaining about > strange difficulties with Maven. After a bit of prodding, they tell us > that they manually created their repo and the pom files, if they exist > at all, are just GAV with no transitive deps. And then they're usually > complaining about how Maven isn't working like they expected. > > I just want to make sure this happens to as few people as possible. If > you know what you're doing and want to check-in some files, please do > it, especially for things like Websphere and Weblogic that will never > appear in the Central repo. > > But doing this for things like commons-* is a bad practice. Even if > you know what you're doing, you probably should not be checking in > files like these manually. > > Wayne > > On 1/31/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > > I've certainly done something similar in the past. To reduce network > traffic, and to better control what libs are used, it is nice to have a > repository on a local server hosting the jars you need. > > > > It is very tempting to just take the set of jars you have always been > using (in an existing ant-based build process or similar) and just upload > them to that new repository. It is certainly easier than finding a maven > repository proxy application, and setting that up. > > > > I don't see a lot wrong with doing that - except that you do need to get > the group ids right! > > > > Of course long-term, having a proper repository manager installed > locally appears to be the right solution. Some day I have to get that > organised for my workplace... > > > > Interesting to see that the war plugin does detect filename clashes; as > discussed in another thread recently it appears that the dependency plugin > does not... > > > > Regards, > > Simon > > > > Wayne Fay <[EMAIL PROTECTED]> schrieb: > > > If you're using "mvn install" or "mvn deploy" to install/deploy common > > > artifacts like commons-logging etc, then you're probably using Maven > > > wrong. > > > > > > What you've described is exactly what the problem was. You had added > > > c-l as a particular G/A/V and then c-l was coming in as a transitive > > > dep under a different G/A/V. Since the plugin detected a name > > > collision, it expanded the name to include the group as well, to make > > > it unique. > > > > > > Why did you install/deploy commons-logging instead of simply adding a > > > ? You're not the first person to report doing this, so I > > > want to understand if there is a failure in the documentation > > > somewhere or if new users are simply making poor assumptions about > > > what Maven does. > > > > > > Wayne > > > > > > On 1/31/08, amit kumar <[EMAIL PROTECTED]> wrote: > > > > I have overcome the problem. And guess know the reason for that, > > > > actually at the time of creating the LAN maven repository, I have > > > > installed common components under org.apache.commons groupId ( > > > > assuming the convention of groupId as package name ). So now when I > > > > was including commons-logging as dependency in my pom.xml, > > > > what I added to pom looked like > > > > > > > > org.apache.commons > > > > commons-logging > > > > 1.1 > > > > > > > > But there was another dependency in my pom.xml which as > > > > commons-logging as transitive dependency with same version, so what > > > > was happening(probably) was that maven instead of overriding the jar > > > > file was renaming it, may be because the jars were differently > > > > identified as groupId+artifactId+version. > > > > Still a little confused about my own explanation of the happenings > :) > > > > > > > > Amit > > > > > > > > On Jan 30, 2008 9:51 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote: > > > > > Looks weird. > > > > > Do you use a released version ? or the current snapshot ? > > > > > > > > > > Could you load an issue in jira with a simple project which > reproduce this ? > > > > > > > > > > -- > > > > > Olivier > > > > > > > > > > 2008/1/30, amit kumar <[EMAIL PROTECTED]>: > > > > > > > > > > > Hi,. > > > > > > When I am packaging a WAR project, I am seeing the following > thing happening... > > > > > > > > > > > > [DEBUG] Processing: commons-logging-1.1.jar > > > > > > [DEBUG] Duplicate found: commons-logging-1.1.jar > > > > > > [DEBUG] Renamed to: commons-logging-commons-logging-1.1.jar > > > > > > > > > > > > Any idea why this happens and how to avoid this? > > > > > > I am mentioning
Re: Lifecycle executions run twice?
you are not understanding lifecycles! "mvn install" means run every stage in the lifecycle upto and including install "mvn deploy" means run every stage in the lifecycle upto and including deploy "mvn install deploy" means run every stage in the lifecycle upto and including install, then run every stage in the lifecycle upto and including deploy so you are asking it to run twice! Since deploy is after install, you should not need to do "mvn install deploy", just "mvn deploy" -Stephen On Feb 1, 2008 10:45 PM, Cam <[EMAIL PROTECTED]> wrote: > Hi, > > I have a project which launches jetty using the cargo plugin - i have it > starting up as part of the initialize phase and tearing down in compile > (i use it for generating stub classes for a web service). If i run the > install or deploy goals on their own it all works great but if i run > "mvn install deploy" after the install phase it tries to start the > container again even though the phase isn't executed again. This ends up > causing class path problems as it's trying to load the war twice not to > mention the extra hit of having to start and stop the container. > > I would have thought that if you specify a phase which is part of a > later phase they would combine to only execute each once, so since the > install goal is included as part of deploy it would effectively be > ignored. What i find really confusing is how the container can be > started after the install phase when it's bound to 'initialize'. > > Thanks, > Cam > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
question about maven-rar-plugin
Why does this plugin not define a packaging of type rar? All the other JavaEE plugins: war, ear, ejb, etc define a packaging. What was the rational behind having this behave differently? Thanks, -Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoid version number in the build
Actually the best procedure is to put the version number in both places. The manifest is not always the easiest to get end users to find for you, and files could be renamed by an end user... but typically if you ask them what version they have it's easier if the jar has the version number in its name. -Stephen On Feb 5, 2008 7:08 AM, amit kumar <[EMAIL PROTECTED]> wrote: > Hi, > How can I avoid version number in the build name and put it in Manifest file.? > Which one is considered a better procedure? > > > Amit > > - > 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: question about maven-rar-plugin
Ahhh, there I go reading the documentation and expecting it to be accurate! The site docs make no mention that it's a valid packaging, so I was thinking that it was a special one! -Stephen Note to self: The Maven2 docs are _never_ accurate until proven otherwise! On Feb 4, 2008 9:13 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote: > Hi, > Have try defining this in your pom rar ? > rar packaging is define in maven core. > > -- > Olivier > > 2008/2/4, Stephen Connolly <[EMAIL PROTECTED]>: > > > Why does this plugin not define a packaging of type rar? > > > > All the other JavaEE plugins: war, ear, ejb, etc define a packaging. > > What was the rational behind having this behave differently? > > > > Thanks, > > > > -Stephen > > > > - > > 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: javax.mail and javax.activation in Java 6
Nooo!
don't go abusing the system path for that
Go with the exclude by default and add back in if jvm is < 6
On Feb 5, 2008 7:49 PM, J Douglas Donohoe <[EMAIL PROTECTED]> wrote:
> Thanks for the suggestion. That led me down the right path. It looks like
> the 'system' scope is more appropriate because in this case, the classes are
> part of the rt.jar. I used the following profile:
>
>
>
> Java 1.6
>
> 1.6
>
>
>
> javax.activation
> activation
> 1.1
> system
> ${java.home}/lib/rt.jar
>
>
>
>
>
> To verify this worked, I used the following command:
>
> $ mvn dependency:build-classpath
>
> The javax.activation jar no longer appears on the classpath, but rt.jar now
> appears (presumably because this plugin defaults to the build classpath).
>
> If I do:
>
> $ mvn dependency:build-classpath -DexcludeScope=system
>
> Then I get the classpath I want.
>
> Thanks for your help.
>
> One question on the use of 'system path' in dependency. Why is this
> necessary at all? If it is part of the system, doesn't javac and/or java
> know where to find it by default?
>
> -Doug
>
> *Note: I'm not sure the system path above will work quite right on a Mac.
> It depends on how Apple decides to package things when they release 1.6.
>
>
> - Original Message
> From: Simon Kitching <[EMAIL PROTECTED]>
> To: Maven Users List
> Cc: Doug Donohoe <[EMAIL PROTECTED]>
> Sent: Tuesday, February 5, 2008 10:57:05 AM
> Subject: Re: javax.mail and javax.activation in Java 6
>
>
> Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> > Hi Maven Community:
> >
> > I have added this dependency in my POM:
> >
> >
> > javax.mail
> > mail
> > 1.4.1
> >
> >
> > Which is retrieved from java.net using this POM definition:
> >
> >
> >
> > java.net
> > http://download.java.net/maven/1
> > legacy
> >
> >
> >
> > The POM for javax.mail declares a dependency on the Java activation
> > framework. However, I am using Java 6 (1.6.0_02), which already
> > includes the activation framework.
> >
> > My question: Is there a way in maven to conditionally define a
> > dependency based on the JDK you are using?
> >
> > If there is, what is the best way for me to use such a mechanism.
> > Ideally, the POM at java.net would be updated, but assuming I can't
> > figure out how to get them to update that, how do I override there
> POM?
> >
>
> Try defining a profile called "java6" in your pom. Set its activation
> section so it only activates for java1.6. Then in the profile define
> that problem dependency with scope=provided.
>
> I think that will do the job. Dependencies declared directly in a pom
> always override those pulled in transiently. That definitely occurs for
> version-numbers, and I *think* it works for scope too.
>
> Regards,
> Simon
>
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javax.mail and javax.activation in Java 6
profile activation based on jvm... i'll do a quick GIYF
On Feb 5, 2008 8:53 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> I'll ask the dumb question..how do you do test the JVM version with maven?
>
> ?
> M-
> - Original Message -
> From: "Stephen Connolly" <[EMAIL PROTECTED]>
> To: "Maven Users List"
>
> Sent: Tuesday, February 05, 2008 3:30 PM
> Subject: Re: javax.mail and javax.activation in Java 6
>
>
> > Nooo!
> >
> > don't go abusing the system path for that
> >
> > Go with the exclude by default and add back in if jvm is < 6
> >
> > On Feb 5, 2008 7:49 PM, J Douglas Donohoe <[EMAIL PROTECTED]> wrote:
> > > Thanks for the suggestion. That led me down the right path. It looks
> like the 'system' scope is more appropriate because in this case, the
> classes are part of the rt.jar. I used the following profile:
> > >
> > >
> > >
> > > Java 1.6
> > >
> > > 1.6
> > >
> > >
> > >
> > > javax.activation
> > > activation
> > > 1.1
> > > system
> > > ${java.home}/lib/rt.jar
> > >
> > >
> > >
> > >
> > >
> > > To verify this worked, I used the following command:
> > >
> > > $ mvn dependency:build-classpath
> > >
> > > The javax.activation jar no longer appears on the classpath, but rt.jar
> now appears (presumably because this plugin defaults to the build
> classpath).
> > >
> > > If I do:
> > >
> > > $ mvn dependency:build-classpath -DexcludeScope=system
> > >
> > > Then I get the classpath I want.
> > >
> > > Thanks for your help.
> > >
> > > One question on the use of 'system path' in dependency. Why is this
> necessary at all? If it is part of the system, doesn't javac and/or java
> know where to find it by default?
> > >
> > > -Doug
> > >
> > > *Note: I'm not sure the system path above will work quite right on a
> Mac. It depends on how Apple decides to package things when they release
> 1.6.
> > >
> > >
> > > - Original Message
> > > From: Simon Kitching <[EMAIL PROTECTED]>
> > > To: Maven Users List
> > > Cc: Doug Donohoe <[EMAIL PROTECTED]>
> > > Sent: Tuesday, February 5, 2008 10:57:05 AM
> > > Subject: Re: javax.mail and javax.activation in Java 6
> > >
> > >
> > > Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> > > > Hi Maven Community:
> > > >
> > > > I have added this dependency in my POM:
> > > >
> > > >
> > > > javax.mail
> > > > mail
> > > > 1.4.1
> > > >
> > > >
> > > > Which is retrieved from java.net using this POM definition:
> > > >
> > > >
> > > >
> > > > java.net
> > > > http://download.java.net/maven/1
> > > > legacy
> > > >
> > > >
> > > >
> > > > The POM for javax.mail declares a dependency on the Java activation
> > > > framework. However, I am using Java 6 (1.6.0_02), which already
> > > > includes the activation framework.
> > > >
> > > > My question: Is there a way in maven to conditionally define a
> > > > dependency based on the JDK you are using?
> > > >
> > > > If there is, what is the best way for me to use such a mechanism.
> > > > Ideally, the POM at java.net would be updated, but assuming I can't
> > > > figure out how to get them to update that, how do I override there
> > > POM?
> > > >
> > >
> > > Try defining a profile called "java6" in your pom. Set its activation
> > > section so it only activates for java1.6. Then in the profile define
> > > that problem dependency with scope=provided.
> > >
> > > I think that will do the job. Dependencies declared directly in a pom
> > > always override those pulled in transiently. That definitely occurs for
> > > version-numbers, and I *think* it works for scope too.
> > >
> > > Regards,
> > > Simon
> > >
> > >
> > >
> > >
> >
>
> > -
> > 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: javax.mail and javax.activation in Java 6
And you know what, Google _Is_ Your Friend:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
The follwing configuration will trigger the profile when the JDK's version
starts with "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"):
1.4
...
So if you are using generics (i.e. don't have to worry about jdk 1.4) you
just have the profile to add the dependency back in activated by 1.5
if you have to worry about 1.4, you'll need two profiles... and if, God
forbid you need to worry about 1.3, three profiles all adding it back in
On Feb 5, 2008 9:09 PM, Stephen Connolly <[EMAIL PROTECTED]>
wrote:
> profile activation based on jvm... i'll do a quick GIYF
>
>
> On Feb 5, 2008 8:53 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > I'll ask the dumb question..how do you do test the JVM version with
maven?
> >
> > ?
> > M-
> > - Original Message -
> > From: "Stephen Connolly" <[EMAIL PROTECTED]>
> > To: "Maven Users List"
> >
> > Sent: Tuesday, February 05, 2008 3:30 PM
> > Subject: Re: javax.mail and javax.activation in Java 6
> >
> >
> > > Nooo!
> > >
> > > don't go abusing the system path for that
> > >
> > > Go with the exclude by default and add back in if jvm is < 6
> > >
> > > On Feb 5, 2008 7:49 PM, J Douglas Donohoe <[EMAIL PROTECTED]> wrote:
> > > > Thanks for the suggestion. That led me down the right path. It
looks
> > like the 'system' scope is more appropriate because in this case, the
> > classes are part of the rt.jar. I used the following profile:
> > > >
> > > >
> > > >
> > > > Java 1.6
> > > >
> > > > 1.6
> > > >
> > > >
> > > >
> > > > javax.activation
> > > > activation
> > > > 1.1
> > > > system
> > > > ${java.home}/lib/rt.jar
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To verify this worked, I used the following command:
> > > >
> > > > $ mvn dependency:build-classpath
> > > >
> > > > The javax.activation jar no longer appears on the classpath, but
rt.jar
> > now appears (presumably because this plugin defaults to the build
> > classpath).
> > > >
> > > > If I do:
> > > >
> > > > $ mvn dependency:build-classpath -DexcludeScope=system
> > > >
> > > > Then I get the classpath I want.
> > > >
> > > > Thanks for your help.
> > > >
> > > > One question on the use of 'system path' in dependency. Why is this
> > necessary at all? If it is part of the system, doesn't javac and/or
java
> > know where to find it by default?
> > > >
> > > > -Doug
> > > >
> > > > *Note: I'm not sure the system path above will work quite right on
a
> > Mac. It depends on how Apple decides to package things when they
release
> > 1.6.
> > > >
> > > >
> > > > - Original Message
> > > > From: Simon Kitching <[EMAIL PROTECTED]>
> > > > To: Maven Users List
> > > > Cc: Doug Donohoe <[EMAIL PROTECTED]>
> > > > Sent: Tuesday, February 5, 2008 10:57:05 AM
> > > > Subject: Re: javax.mail and javax.activation in Java 6
> > > >
> > > >
> > > > Doug Donohoe <[EMAIL PROTECTED]> schrieb:
> > > > > Hi Maven Community:
> > > > >
> > > > > I have added this dependency in my POM:
> > > > >
> > > > >
> > > > > javax.mail
> > > > > mail
> > > > > 1.4.1
> > > > >
> > > > >
> > > > > Which is retrieved from java.net using this POM definition:
> > > > >
> > > > >
> > > > >
> > > > > java.net
> > > > > http://download.java.net/maven/1
> > > > > legacy
> > > > >
> > > > >
> > > > >
> > > > > The POM for javax.mail declares a dependency on the Java
activation
> > > > > framework. However, I am using Java 6 (1.6.0_02), which already
> &
Re: javax.mail and javax.activation in Java 6
Look, maven only works on JDK 1.3 or higher...
you have three profiles
javax.mail
mail
1.4.1
... (see documentation) ...
jdk13
1.3
javax.activation
activation
1.1
jdk14
1.4
javax.activation
activation
1.1
jdk15
1.5
javax.activation
activation
1.1
Which is actually quite elegant, as each jdk includes more than the
previous, so if there are dependencies that are in JDK 1.5 but not JDK1.4,
you can add them only to jdk14 profile, etc.
Quit with the environment variable stuff as your build will not be
reproducible... if you want to do that kind of stuff I'd either switch to
ANT or write a plugin
On Feb 5, 2008 9:41 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> the only possible suggestion is to set JAVA_VERSION environment variable
> to
> whatever_it_is..(probably implement this in .profile for login..?)
> and then test it thru a Character Data script i.e.
>
>
>
>
>
>
>
>
>
>
> Anyone else?
> M-
> - Original Message -
> From: "Stephen Connolly" <[EMAIL PROTECTED]>
> To: "Maven Users List"
> Sent: Tuesday, February 05, 2008 4:12 PM
> Subject: Re: javax.mail and javax.activation in Java 6
>
>
> > And you know what, Google _Is_ Your Friend:
> >
> >
> http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> >
> > The follwing configuration will trigger the profile when the JDK's
> version
> > starts with "1.4" (eg. "1.4.0_08", "1.4.2_07", "1.4"):
> >
> >
> >
> >
> > 1.4
> >
> >...
> >
> >
> >
> > So if you are using generics (i.e. don't have to worry about jdk 1.4)
> you
> > just have the profile to add the dependency back in activated by
> 1.5
> >
> >
> > if you have to worry about 1.4, you'll need two profiles... and if, God
> > forbid you need to worry about 1.3, three profiles all adding it back in
> >
> > On Feb 5, 2008 9:09 PM, Stephen Connolly <
> [EMAIL PROTECTED]>
> > wrote:
> > > profile activation based on jvm... i'll do a quick GIYF
> > >
> > >
> > > On Feb 5, 2008 8:53 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > > > I'll ask the dumb question..how do you do test the JVM version with
> > maven?
> > > >
> > > > ?
> > > > M-
> > > > - Original Message -
> > > > From: "Stephen Connolly" <[EMAIL PROTECTED]>
> > > > To: "Maven Users List"
> > > >
> > > > Sent: Tuesday, February 05, 2008 3:30 PM
> > > > Subject: Re: javax.mail and javax.activation in Java 6
> > > >
> > > >
> > > > > Nooo!
> > > > >
> > > > > don't go abusing the system path for that
> > > > >
> > > > > Go with the exclude by default and add back in if jvm is < 6
> > > > >
> > > > > On Feb 5, 2008 7:49 PM, J Douglas Donohoe <[EMAIL PROTECTED]>
> wrote:
> > > > > > Thanks for the suggestion. That led me down the right path. It
> > looks
> > > > like the 'system' scope is more appropriate because in this case,
> the
> > > > classes are part of the rt.jar. I used the following profile:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Java 1.6
> > > > > >
> > > > > > 1.6
> > > > > >
> > > > > >
> > > > > >
> > > > > > javax.activation
> > > > > > activation
> > > > > > 1.1
> > > > > > system
> > > > > > ${java.home}/lib/rt.jar
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > To verify this worked, I used the following command:
> > > > > >
> > > > > > $ mvn dependency:build-classpath
> > > > > >
> > > > > > The javax.activation jar no longer appears on the classpath, but
&
Re: javax.mail and javax.activation in Java 6
Well the problem I see is that of dependencies being added to the jvm. Fundamentally javax.activation should be scope "provided"... as it's up to the consumer of your api to ensure it is available. The api that is dragging in javax.activation has it as scope "compile"... which is why it is ending up transitively as a dependency. The issue is that we have not got documentation which indicates what modules are in the java run time classpath. If Maven had that knowledge, then you could flag, at least for unit tests and launching by Maven, that the dependency has not been provided either explicitly or by the jvm's rt The consumer of your code, though, still has to ensure that they provide the api's that are required by your code, i.e. those with a scope of provided. I think you maybe confusing running your code from within Maven with running outside of Maven. If ANT "has greater capability" it is to hide this classpath complexity from you (as a developer) while developing... once you turn around to deploying in a mixed environment, ant will have hidden the problem from you very much and you will be more stuck than before. One way out of your problems that I see would be to have a jdk6-backport artifact with a number of classifiers, one for each jdk that you want to support. The backport artifact can be an empty jar with just dependencies on the missing modules that the earlier jdks do not have (w.r.t. jdk6) Thus each system need only pull in it's backport artifact as a dependency. a central dependencyManagement section in the common parent pom that is activated based on the jdk would then select the appropriate classifier for your runtime environment, and each child module need only declare a scope runtime dependency on the jdk6-backport artifact (without providing version or classifier) thus indicating this complex relationship On Feb 5, 2008 11:34 PM, Martin Gainty <[EMAIL PROTECTED]> wrote: > looking for scenarios which will work for all jvm versions (and not forcing > the implementor to individually handle jvm specific scenarios) > ANT certainly has greater capability (at least with this scenario) > > but still looking forward to a maven based solution > > Thanks > Martin > - Original Message - > From: "Stephen Connolly" <[EMAIL PROTECTED]> > To: "Maven Users List" > > Sent: Tuesday, February 05, 2008 5:18 PM > Subject: Re: javax.mail and javax.activation in Java 6 > > > > Look, maven only works on JDK 1.3 or higher... > > > > you have three profiles > > > > > > > > javax.mail > > mail > > 1.4.1 > > > > ... (see documentation) ... > > > > > > > > > > > > jdk13 > > > > 1.3 > > > > > > > >javax.activation > >activation > > 1.1 > > > > > > > > > > jdk14 > > > > 1.4 > > > > > > > >javax.activation > >activation > >1.1 > > > > > > > > > > jdk15 > > > > 1.5 > > > > > > > >javax.activation > >activation > > 1.1 > > > > > > > > > > > > Which is actually quite elegant, as each jdk includes more than the > > previous, so if there are dependencies that are in JDK 1.5 but not JDK1.4, > > you can add them only to jdk14 profile, etc. > > > > Quit with the environment variable stuff as your build will not be > > reproducible... if you want to do that kind of stuff I'd either switch to > > ANT or write a plugin > > > > > > On Feb 5, 2008 9:41 PM, Martin Gainty <[EMAIL PROTECTED]> wrote: > > > > > the only possible suggestion is to set JAVA_VERSION environment variable > > > to > > > whatever_it_is..(probably implement this in .profile for login..?) > > > and then test it thru a Character Data script i.e. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone else? > > > M- > > > - Original Message - > > > From: "Stephen Connolly" <[EMAIL PROTECTED]> > > > To: "Maven Users List" > > > Sent: Tuesday, February 05, 2008 4:12 PM > > > Subject: Re: javax.mail and javax.activation in Java 6 > > > > > > > > > &
Re: Strange problems with mvn release:perform when running javadoc:jar on Windows
Found the solution... he had his CLASSPATH environment variable set and it was pulling in all sorts of junk from a previous version of the JDK On Jan 18, 2008 12:36 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > oh it gets stranger. > > we have no problems with javadoc:javadoc, only javadoc:jar > > > > On Jan 18, 2008 9:57 AM, Tom Huybrechts <[EMAIL PROTECTED] > wrote: > > I've had my share of javadoc problems, but not this one. Did you try to > run > > the javadoc command itself from the commandline ? > > > > Tom > > > > On Jan 18, 2008 10:48 AM, Stephen Connolly > <[EMAIL PROTECTED]> > > > > > > > > wrote: > > > > > Anyone??? or will i just file an issue > > > > > > On Jan 17, 2008 8:24 AM, Stephen Connolly > <[EMAIL PROTECTED] > > > > > > > wrote: > > > > > > > Here is the stacktrace: > > > > > > > > The exact same commands from my machine work with the exact same > > > proxyHost > > > > and proxyPort and JDK and Maven version > > > > > > > > [INFO] [javadoc:jar] > > > > [DEBUG] C:\Java\jdk1.6.0_04\jre\..\bin\javadoc.exe > > > > -J-DproxyHost=.com -J-DproxyPort= @options @packages > > > > Loading source files for package com.... > > > > Constructing Javadoc information... > > > > Standard Doclet version 1.6.0_04 > > > > Building tree for all the packages and classes... > > > > Generating > > > > > > > > C:/work/jsr-112-workmanager-impl/target/apidocs\com/___/___/___//\_.html... > > > > [INFO] > > > > > > > > > [ERROR] BUILD ERROR > > > > [INFO] > > > > > > > > > [INFO] Error while creating archive:Exit code: 1 - > > > > java.lang.IllegalArgumentException > > > > at sun.net.www.ParseUtil.decode(ParseUtil.java:189) > > > > at sun.misc.URLClassPath$FileLoader .(URLClassPath.java:953) > > > > at sun.misc.URLClassPath$3.run(URLClassPath.java:326) > > > > at java.security.AccessController.doPrivileged(Native Method) > > > > at sun.misc.URLClassPath.getLoader (URLClassPath.java:320) > > > > at sun.misc.URLClassPath.getLoader(URLClassPath.java:297) > > > > at sun.misc.URLClassPath.findResource(URLClassPath.java:144) > > > > at java.net.URLClassLoader$2.run(URLClassLoader.java :362) > > > > at java.security.AccessController.doPrivileged(Native Method) > > > > at java.net.URLClassLoader.findResource(URLClassLoader.java:359) > > > > at java.lang.ClassLoader.getResource(ClassLoader.java :977) > > > > at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1159) > > > > at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96) > > > > at java.security.AccessController.doPrivileged (Native Method) > > > > at javax.xml.parsers.SecuritySupport.getResourceAsStream( > > > > SecuritySupport.java:89) > > > > at javax.xml.parsers.FactoryFinder.findJarServiceProvider( > > > > FactoryFinder.java :250) > > > > at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223) > > > > at > javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java > > > > :128) > > > > at > > > com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML ( > > > > LayoutParser.java:72) > > > > at > com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build( > > > > ClassBuilder.java:108) > > > > at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles ( > > > > HtmlDoclet.java:155) > > > > at > > > > > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles > > > ( > > > > AbstractDoclet.java:164) > > > > at > > > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration ( > > > > AbstractDoclet.java:106) > > > > at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start( > > > > AbstractDoclet.java:64) > > > > at com.sun.tools.doclets.formats.html.HtmlDoclet.start > (HtmlDoclet.java > > > > :42) > > > > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > > >
Re: conditional dependencies
The problem I see with conditional dependencies is that they define the dependencies that Maven needs in order to build/test the artifact. So if I do a build on java6, my conditional dependencies will exclude javax.activation... I assume the Release/deploy plugins will upload the effective pom for my build environment, which does not include javax.activation... Now you come along and depend on my artifact, but are building with java5... so you do not receive the conditional dependency. On the other hand if the release/deploy plugins upload the pom and it's profile definitions, Maven is going to have to re-detect the profile activation to determine the transitive dependencies (Which I don't thinkk it does) -Stephen On Feb 5, 2008 8:20 AM, SlinnHawkins, Jon (ELS-CAM) < [EMAIL PROTECTED]> wrote: > Hi Jorg > > Yeah just set up profiles for Java5 and java6 each specifying the unique > dependencies for the jdk. > > Jon > > -Original Message- > From: Joerg Hohwiller [mailto:[EMAIL PROTECTED] > Sent: 04 February 2008 21:13 > To: Maven Users List > Subject: conditional dependencies > > Hi there, > > I am using conditional dependencies in the form that I use variables in > the dependencies and profiles to set these variables. > > Now I currently wonder what to do if a dependency is only required under > specific situations. E.g. stax or jsr250 is included in java6 while you > need dependencies on external artifacts for java5. > Has someone experience with that? > Is it best to use a variable for the scope and set it to "provided" for > java6? > Or is it possible to add a dependency into the profile section? > > Thanks > Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > This email is from Elsevier Limited, a company registered in England and > Wales with company number 1982084, > whose registered office is The Boulevard, Langford Lane, Kidlington, > Oxford, OX5 1GB, United Kingdom. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Maven Concepts
Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will not re-download it. This is why -SNAPSHOT versions are needed (because Maven knows to check for updates). But another reason why the update may not have occurred is if the artifact was copied into the remote repository and not deployed using one of: - mvn deploy:deploy - mvn deploy:deploy-file - maven ant tasks (which are a set of tasks that can be used from ant build scripts to download artifacts from maven repositories or deploy files to maven repositories) These three methods of deploying to the remote repository will ensure that the repository metadata is updated. If you "just copy the file" then maven can be unaware of this version as it checks the metadata first -Stephen On Feb 8, 2008 7:37 AM, Sahoo <[EMAIL PROTECTED]> wrote: > I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends > with -SNAPSHOT) version then maven checks the timestamp etc. against the > remote repository. Otherwise Maven always prefers the one in the local > repository if one is available there. In your case, the artifact version > looks to be 1.0 which means once the artifact is available in your local > repo, maven won't go to remote repo for that one. Question why did the > owner of the artifact chose to update the artifact, but did not bother > to change the version number? > > Someone can correct me if need be. > > Thanks, > Sahoo > amit kumar wrote: > > Continuing on this thread I would also like to put a > doubt(misconception)- > > Until yesterday I used to think that if I have an artifact on local > > repository + remote repository with same groupId-artifactId-version. The > > maven will take the one which is built at a later time or some system > > property attached to it which maven uses to differentiate. > > > > The origin for this assumption was no matter if the artifact is present > in > > my local repository maven shows > > > > Downloading \\remoteRepository\org\apache\x\x-1.0.pom > > Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom > > . > > . > > . > > . > > . > > What I assumed of this was that it compares where the latest of the > artifact > > is available even with same groupId+artifactId+version. > > > > But yesterday when I cross checked even at the remote repository had a > > artifact newly deployed (though with same groupId+artifactId+versionId) > what > > I was seeing in the classpath was the one from local repository. > > > > Am I right in what I am concluding? Or again missing somewhere. > > > > If what I have concluded upon is right, is there a way to make maven > pick up > > the one from remote repository(in case it is build and deployed later? ) > > > > > > Thanks and regards, > > Amit > > > > > > On Feb 8, 2008 4:55 AM, Graham Leggett <[EMAIL PROTECTED]> wrote: > > > > > >> Dhruva Reddy wrote: > >> > >> > >>> What exactly is a goal and what is a phase? > >>> > >> In maven 1, there were only goals, and goals were specific targets that > >> were embedded in specific maven plugins, a bit like an ant target. > >> > >> So the jar plugin would have the jar goal which when run, would jar up > >> some classes. > >> > >> It soon became apparent that this leaves too much up to the end user: > >> what if the artifact you are producing isn't a jar, but an ear instead? > >> Or a war file? Why should the user have to know or care that they must > >> run the ear:ear goal instead of the jar:jar goal? > >> > >> Enter the phases of the lifecycle in maven 2. > >> > >> Plugins attach various goals to the various phases in the lifecycles, > >> and depending on which phase of the lifecycle you've asked maven to > >> complete, all the relevant goals attached to that lifecycle will be run > >> up to that phase. > >> > >> So if you run "mvn install" (or "run all goals in all phases up until > >> the 'install' phase"), maven figures out for itself that the > >> compile:compile goal must run, and the ear:ear goal (because the > >> artifact is an ear file), the user no longer needs to care. > >> > >> So to sum up: > >> > >> The lifecycle contains a list of phases, and each phase has a goal or > >> goals attached to that phase. So running a phase is a convenient way of > >> saying "run all goals I need to run to make this artifact up to this > >> phase, and don't tell me what those goals are, I don't care". > >> > >> Regards, > >> Graham > >> -- > >> > >> > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Javadoc plugin bug/issue reprised
Have you got multiple Java VM's installed on your system. We had one developer who had multiple VM's installed and had a CLASSPATH environment variable that pointed to a different JVM than the one he was running Maven from, which caused problems with Javadoc. The solution was to clear his CLASSPATH environment variable On Feb 8, 2008 11:09 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > If you're reasonably certain you've found a bug (and it sounds like > you have), and have a work-around/better solution, then please do file > a JIRA bug and attach your patch. > > I have no idea why it is using java.vm.version rather than > java.version, but I'd assume there's a reason. Perhaps your patch > could read from both, and then pick the best fitting VM out of the 2 > property strings. > > Wayne > > On 2/8/08, Alexander Sack <[EMAIL PROTECTED]> wrote: > > So I figured out the issue and I was wondering if I could get a little > > guidance. The javadoc plugin when it executes the javadoc:javadoc goal > > attempts to determine the version of the VM its running. I suspect its > > parsing the java.vm.version string. On the platform I'm on, that is > > different than the expected 1.5.x etc. format. Its actually > > OS-VERSION-VMVERSION format which causes a NumberFormatException when > > javadoc is ran the plugin. > > Is there any reason why it isn't using the java.version System property > > instead which is more generic across different Java implementations? I > had > > a very similar issue with another plugin (native2ascii) that was > assuming > > certain things about the platform. > > > > Any guidance would be appreciated, > > > > -aps > > > > -- > > "What lies behind us and what lies in front of us is of little concern > to > > what lies within us." -Ralph Waldo Emerson > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Surefire not picking up tests from test-jar
I don't know if it ever worked. I switched to the dependency hack. somebody needs to update the dogs that claim you can do this though On 2/12/08, Dan Fabulich <[EMAIL PROTECTED]> wrote: > Stephen Connolly wrote: > > > Has anybody tried running a test-jar with Surefire 2.4.1? > > > > It's not picking up any of our unit tests from the test jar. > > > > We're using JUnit 4.4 (but the tests in the test jar are all JUnit 3.8.1) > > > > It's picking up the unit tests from src/test/java fine, but we have > packaged > > our compatability tests are in a separate jar file so that they can be > used > > across the two modules that must be compatable. > > When you say "with Surefire 2.4.1" do you mean that this used to work in > an earlier version? > > Based on what I think I know about Surefire, it would surprise me if this > ever worked. The algorithm for finding tests searches for .class files in > target/test-classes. > > One workaround would be to use maven-dependency-plugin to unpack your > test-jar(s) into the target/test-classes directory. > > If this is a regression, please file an issue in JIRA with a minimal Maven > project that reproduces the problem. (In this case, I think the > appropriate thing would be a simple reactor build that installs a test-jar > in one sub-project and tries to run its tests in a second sub-project.) > > -Dan > > - > 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: Surefire not picking up tests from test-jar
On Feb 12, 2008 7:13 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > somebody needs to update the dogs that claim you can do this though Damn typing on the iTouch! I t was supposed to be update the docs
Surefire not picking up tests from test-jar
Has anybody tried running a test-jar with Surefire 2.4.1? It's not picking up any of our unit tests from the test jar. We're using JUnit 4.4 (but the tests in the test jar are all JUnit 3.8.1) It's picking up the unit tests from src/test/java fine, but we have packaged our compatability tests are in a separate jar file so that they can be used across the two modules that must be compatable. -Stephen
Re: damage image files
I use src/main/resources/filtered true src/main/resources/verbatim false As it describes exactly what happens to it's contained resources On Feb 13, 2008 11:56 AM, John Coleman < [EMAIL PROTECTED]> wrote: > I think we will try something like this > > >src/main/resources/cfg >true > > >src/main/resources/bin > > > This separate our configurable text file resources from our binaries, > should do the trick. > > > -Original Message- > > From: Rémy Sanlaville [mailto:[EMAIL PROTECTED] > > Sent: 13 February 2008 10:07 > > To: Maven Users List > > Subject: Re: damage image files > > > > Hi John, > > > > It's amazing that we had the same problem yesterday. > > It seems that it comes from filter but not sure for the moment. > > > > I will try to create a simple example project in order to can > > reproduce the problem. > > > > Rémy > > > > Eurobase International Limited and its subsidiaries (Eurobase) are unable > to exercise control over the content of information in E-Mails. Any views > and opinions expressed may be personal to the sender and are not necessarily > those of Eurobase. Eurobase will not enter into any contractual obligations > in respect of any part of its business in any E-mail. > > Privileged / confidential information may be contained in this message and > /or any attachments. This E-mail is intended for the use of the addressee(s) > only and may contain confidential information. If you are not the / an > intended recipient, you are hereby notified that any use or dissemination of > this communication is strictly prohibited. If you receive this transmission > in error, please notify us immediately, and then delete this E-mail. > > Neither the sender nor Eurobase accepts any liability whatsoever for any > defects of any kind either in or arising from this E-mail transmission. > E-Mail transmission cannot be guaranteed to be secure or error-free, as > messages can be intercepted, lost, corrupted, destroyed, contain viruses, or > arrive late or incomplete. Eurobase does not accept any responsibility for > viruses and it is your responsibility to scan any attachments. > > Eurobase Systems Limited is the main trading company in the Eurobase > International Group; registered in England and Wales as company number > 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex > CM2 0RE, UK. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: not able to deploy using webdav
I keep on telling everyone to use freestyle. It's a running joke between myself and Peter Reilly (of ANT fame) that 90% of the issues with Hudson are the Maven project type! On a side note I have a plan for giving people what they like of the Maven project type (i.e. modularised sub-reports) with the stability of the freestyle project type, but I have not had the chance to roll it out yet -Stephen On Feb 13, 2008 10:14 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I haven't had much luck with the build in maven support, but you can set > it up very easily as a freestyle project. Hudson is rock solid and the > only thing I use. > > -Original Message- > From: Savita_p_m [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 13, 2008 12:22 PM > To: users@maven.apache.org > Subject: Re: not able to deploy using webdav > > > Hi, > > Thanks for the pointer... > > However my issues was related to hudson configuration as it was working > fine > with command line. > > Hudson job configuration using " Build a maven2 project (beta)" doesn't > work > with webdav where as same thing worked for me when I configured the job > using "Build a free-style software project" and selected maven-2.0.6 for > maven builds. > > May help to someone who is facing the similar issue. > > > Regards > Savita > > > Savita_p_m wrote: > > > > Hi, > > > > I am getting following error while trying for site-deploy, I have > > configured job using hudson to run maven goals. Build extensions are > > mentioned in pom.xml and the repository has the wagon-webdav jars. > > > > However from command line it works properly where as it fails with the > > following error when configured through hudson. > > > > > > [INFO] Error deploying artifact: Unsupported Protocol: 'dav': Cannot > find > > wagon which supports the requested protocol: dav > > > > Component descriptor cannot be found in the component repository: > > org.apache.maven.wagon.Wagondav. > > > > > > Kindly help me if some one know the solution to this. > > > > > > > > -- > View this message in context: > http://www.nabble.com/not-able-to-deploy-using-webdav-tp15450557s177p154 > 67004.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] > >
Re: surefire-report-plugin running tests of all dependent modules again?
Currently the only way I know is to use the enforcer plugin (but a version newer than 1.0-alpha-3) with the require plugin versions rule enabled. Then just repeatedly call mvn validate and it will keep on telling you what plugins are missing versions. I think the plan is to add the functionality to the enforcer or the help plugin, so that you'd have something like mvn enforcer:display-plugin-versions or mvn help:display-plugin-versions I agree that the release plugin should insert the plugin versions. I think this is the idea behind the generate release poms option, but I have not been able to get that option to work how I think it should work -Stephen On Thu, Feb 14, 2008 at 4:30 AM, Trevor Torrez <[EMAIL PROTECTED]> wrote: > I would like to second this sentiment. Is there a plugin that can add > the current plugin version information to the pom? I also definately > think this information should be added to poms processed with the > release plugin (if it isn't already). > > Thanks > > On Jan 29, 2008 5:49 PM, Joerg Hohwiller <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > | Hi Jörg, > > Hi Stefan, > > | > > | this is also what I see here (see my post about "M2 multi-project site > > | build is broken"). > > | All tests are run for each project in the reactor. I think we could > file > > | an issue for each of the affected plugins, but this seems more like a > > | maven generic issue. Something was "fixed" with devastating effects > for > > | a lot of plugins. What maven version are you using? > > I am using maven 2.0.8 > > Everything works fine if I explicitly set the version of the > > surefire-report-plugin to 2.3 and goes wrong if I use 2.4 > > I did not have the same problem with other plugins. > > Could you track this down? > > Though I know that the latest site-plugin is buggy as well as the latest > > javadoc-plugin. But this are other problems. > > If you want freedom with maven you need to define the versions > > of all plugins explicitly in your toplevel pom. That is what I learned > in a > > bloody bad lessen with maven. The plugin developers often do not know > the impact > > of releasing buggy plugins. There are thousands of maven users that > suddenly > > have a broken build and no idea what is wrong. > > I am using maven from the early days now and switched to maven2 over 2,5 > years > > ago. With maven2 I want to build my code and the project website. > > The site of a multi-project build was a problem for years and even > though > > patches are attached to jira for fixing related plugins such as > cobertura it is > > still not fixed. Sometimes you need to be patient. However maven2 is > excellent > > already and I have big hopes for maven 2.1 all that is going on with > mojo, etc. > > After a lot of pain with maven1 I am happy to see a product with a > design and > > a concept. Thanks to all the great workers of the maven team! > > | > > | Stefan > > > > Regards Jörg > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.5 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFHn62GmPuec2Dcv/8RAtzeAJ92rvs3JmZmkseghuWYW1/N+GsDRQCfXSxI > > 8P1+VCIkc4HEJIKxZjXnZZs= > > =SZo2 > > > > -END PGP SIGNATURE- > > > > - > > 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: Dependencies...
provided On Feb 16, 2008 7:05 PM, James Carman <[EMAIL PROTECTED]> wrote: > What is the "maven way" of doing this? Suppose a library you're > writing requires Spring. You write your library against an older > version of Spring (2.0) and you define it as a dependency. Now, when > other projects want to use your library, spring-2.0.jar will be > included in their classpath as a transitive dependency. But, what if > the project wants to use Spring 2.5.1? They would have to do an > exclusion on their dependency to tell it not to include the > spring-2.0.jar, right? What scope should the library put on the > spring dependency so that any projects using that library can provide > their own version of spring? > > James > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Deleting files in Maven
maven-antrun-plugin unless you're using maven 1.x! On Feb 16, 2008 6:45 AM, Samavedula, Ravi (GE Healthcare, consultant) < [EMAIL PROTECTED]> wrote: > Hi all, > i want to delete files using maven not using ant is there any tag for > doing this. > > Thanks in Advance > Ravi S >
Re: Does Maven dependency only work with jar?
eh! technically he _could_ add a packaging of type class and have one (1) maven project for each class file ;-) [i.e. the five class files that he does not want to jar up would each have their own maven project, and hope that they don't reference each other in a circular fashion or he's screwed] but in fairness, who'd want to go to all that trouble, writing a class-maven-plugin... Of course at that point he'd then hit how to get those classes into the java class path for the compiler etc plugins... so then he's writing a new compiler and surefire-type plugin that understands class dependencies... I'd give an estimate of about 12-15 months to get all that working... On the other hand, if he packages them up in a jar, that's maybe 12-15 seconds to get that working... So to summarise: fight the system -> months use a jar -> seconds It's his choice! ;-) -Stephen On Feb 20, 2008 5:59 AM, Wayne Fay <[EMAIL PROTECTED]> wrote: > You can't. Don't fight the system and you'll be a generally happier > person. Package the class files into a Jar. > > Wayne > > On Feb 19, 2008 7:37 PM, youhaodeyi <[EMAIL PROTECTED]> wrote: > > > > I have some *.class files in a directory. I know I can make them into a > jar > > file and add it to the dependency of Maven, but I don't want to package > > them. How can I set the dependency in Maven to add this directory to > > classpath? > > -- > > View this message in context: > http://www.nabble.com/Does-Maven-dependency-only-work-with-jar--tp15580501s177p15580501.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] > >
Re: assembly plugin and project inheritance
You could attach the common descriptor as a build artifact one module, and then use the dependency plugin to pull it down to each child module. i.e. Use buildhelper-maven-plugin in rwcf-apps to attach dist.xml with a classifier of, e.g. assembly-descriptor. Now when you run mvn install or mvn deploy on rwcf-apps the descriptor will be published to the maven repository (local or remote respectively) Then in one of the modules that you want to use this common descriptor, add a dependency on the rwcf-apps with a type of assembly-descriptor, you use maven-dependency-plugin to copy the dependency to your target directory, and then your pom just directs the assembly plugin to use that descriptor. -Stephen On Thu, Feb 21, 2008 at 8:47 PM, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote: > Hello > > I'm having many projects that share some dependencies and that should be > packaged the same way. So I wanted to have a parent project configuring > the maven-assembly-plugin. > > I did this with the following in the parent pom: > > > >maven-assembly-plugin > > > > ../rwcf-apps/src/assembly/dist.xml > > > > > This only works when the parent is checked out in a sibling directory of > the child. If one just check out a child project without checking out > the parent assembly:assembly wont work. Things work using a > descriptorRef but the predefined descriptors don't do what I'm looking > for. > > Possibly ways to solve the issues might be: > >* have the plugin look up the descriptor from the parent rather >* reference a descriptor with an http uri >* include the content of descriptor directly in the pom > > ...but I didn't find a way to do it in any of these ways. > > Any suggestion on how to make it possible to check out a single > child-project and being able to assemble it? > > If you would like to know more precisely what I'm doing, you may look at > >* The descriptor: > > https://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps/trunk/src/assembly/dist.xml >* The parent pom: > > https://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps/trunk/pom.xml >* A child pom: > > https://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-app-webdav/trunk/pom.xml > > Cheers, > reto > >
Re: assembly plugin and project inheritance
there are two sets of goals in the maven dependency plugin.
the first set are copy and unpack. you specify the artifacts inside
the plugin configuration. these are not the set you want. the set you
want are copy-dependencies (or something like that I am on my iPod so
you will have to check) with this set you add the dependency to the
pom. that will force maven to sequence things correctly for you.
the build helper plugin has a default phase, so leave that alone. I
would bind the dependency plugin to one of the generate phases
(sources or resources)
Stephen
2/22/08, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote:
> The version I posted doesn't work as the child-projects can't perform
> the attach-artifact attached to the package phase.
>
> I've now extracted the dist configuration and the attachment of it to a
> separate project[1]. Having done this I also attached the copy and the
> assembly goals to the compile and package phases [2].
>
>
> 1.
> http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps-assembly/trunk/pom.xml
> 2. in
> http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps/trunk/pom.xml
>
>
> Reto Bachmann-Gmür wrote:
> > Thanks Stephen,
> >
> > trying to follow the path you describe I added the following to the
> > parent-pom:
> >
> >
> > org.codehaus.mojo
> > build-helper-maven-plugin
> >
> >
> > attach-artifacts
> > package
> >
> > attach-artifact
> >
> >
> >
> >
> > src/assembly/dist.xml
> > xml
> >
> > assembly-descriptor
> >
> >
> >
> >
> >
> >
> >
> >
> > and
> >
> > org.apache.maven.plugins
> > maven-dependency-plugin
> >
> >
> >
> > org.wymiwyg.rwcf
> > rwcf-apps
> > 0.0.1
> > xml
> > assembly-descriptor
> > false
> >
> > ${project.build.directory}/src/assembly/
> >
> > dist.xml
> >
> >
> >
> >
> >
> > furthermore I changed the descriptor of maven-assembly-plugin to use
> > ${project.build.directory}/src/assembly/dist.xml. I didn't change
> > anything to the child-projects.
> >
> > I can now execute "mvn clean dependency:copy assembly:assembly" for
> > child projects to create a distribution-package.
> >
> > The only thing which I'm still insecure is about attaching this to
> > phases, the difficulty seems that the super project doesn't need to
> > have this attached to any phase, and the dependency resolution fails
> > unless executed after install (a solution might be to split the parent
> > into a grand-parent providing the assembly descriptor and binding it
> > to phases in the intermediate parent). But I'm not sure anyway in
> > which phase to best create zip and tar.
> >
> > Cheers,
> > reto
> >
> > Stephen Connolly wrote:
> >> You could attach the common descriptor as a build artifact one
> >> module, and
> >> then use the dependency plugin to pull it down to each child module.
> >>
> >> i.e.
> >>
> >> Use buildhelper-maven-plugin in rwcf-apps to attach dist.xml with a
> >> classifier of, e.g. assembly-descriptor.
> >> Now when you run mvn install or mvn deploy on rwcf-apps the
> >> descriptor will
> >> be published to the maven repository (local or remote respectively)
> >>
> >> Then in one of the modules that you want to use this common
> >> descriptor, add
> >> a dependency on the rwcf-apps with a type of assembly-descriptor, you
> >> use
> >> maven-dependency-plugin to copy the dependency to your target
> >> directory, and
> >> then your pom just directs the assembly plugin to use that descriptor.
> >>
> >> -Stephen
> >>
> >> On Thu, Feb 21, 2008 at 8:47 PM, Reto Bachmann-Gmür <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>
> >>> Hello
> >>>
> >>> I'm having many projects that share some dependencies and that
> >>> should be
> >>> packaged the same way. So I wanted to have a parent project configuring
> >>> the maven-assembly-plugin.
> >>>
> >>> I did this with the following in the parent pom:
> >>>
> >>>
> >>>
> >>> maven-assembly-plugin
> >>>
> >>>
> >>>
> >>> ../rwcf-apps/src/assembly/dist.xml
> >>>
> >>>
> >>>
> >>>
> >>> T
Re: assembly plugin and project inheritance
Copy requires that the artifact must be in the local repository or in a
remote repository.
The copy dependencies allows for the artifact to come from the reactor, so
you don't have to install the artifact into your local repository.
The copy dependencies can be set to only copy one dependency.
Trust me, this is the better way to do it.
-Stephen
On Sat, Feb 23, 2008 at 9:38 PM, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote:
> Thank you very much for your help, I can now have many projects generate
> the right assembly with just one assembly descriptor and without
> requiring to check out multiple projects (and having them at the right
> position in the directory structure).
>
> I don't understand your suggestion to use copy-dependencies, what I'm
> doing is copying a single resource (the assembly descriptor) and not all
> of the dependencies. The copy goal seems to do its job.
>
> Cheers,
> reto
>
>
>
> Stephen Connolly wrote:
> > there are two sets of goals in the maven dependency plugin.
> >
> > the first set are copy and unpack. you specify the artifacts inside
> > the plugin configuration. these are not the set you want. the set you
> > want are copy-dependencies (or something like that I am on my iPod so
> > you will have to check) with this set you add the dependency to the
> > pom. that will force maven to sequence things correctly for you.
> >
> > the build helper plugin has a default phase, so leave that alone. I
> > would bind the dependency plugin to one of the generate phases
> > (sources or resources)
> >
> > Stephen
> > 2/22/08, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote:
> >
> >> The version I posted doesn't work as the child-projects can't perform
> >> the attach-artifact attached to the package phase.
> >>
> >> I've now extracted the dist configuration and the attachment of it to a
> >> separate project[1]. Having done this I also attached the copy and the
> >> assembly goals to the compile and package phases [2].
> >>
> >>
> >> 1.
> >>
> http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps-assembly/trunk/pom.xml
> >> 2. in
> >>
> http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps/trunk/pom.xml
> >>
> >>
> >> Reto Bachmann-Gmür wrote:
> >>
> >>> Thanks Stephen,
> >>>
> >>> trying to follow the path you describe I added the following to the
> >>> parent-pom:
> >>>
> >>>
> >>> org.codehaus.mojo
> >>> build-helper-maven-plugin
> >>>
> >>>
> >>> attach-artifacts
> >>> package
> >>>
> >>> attach-artifact
> >>>
> >>>
> >>>
> >>>
> >>> src/assembly/dist.xml
> >>> xml
> >>>
> >>> assembly-descriptor
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> and
> >>>
> >>> org.apache.maven.plugins
> >>> maven-dependency-plugin
> >>>
> >>>
> >>>
> >>> org.wymiwyg.rwcf
> >>> rwcf-apps
> >>> 0.0.1
> >>> xml
> >>> assembly-descriptor
> >>> false
> >>>
> >>> ${project.build.directory}/src/assembly/
> >>>
> >>> dist.xml
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> furthermore I changed the descriptor of maven-assembly-plugin to use
> >>> ${project.build.directory}/src/assembly/dist.xml. I didn't change
> >>> anything to the child-projects.
> >>>
> >>> I can now execute "mvn clean dependency:copy assembly:assembly" for
> >>> child projects to create a distribution-package.
> >>>
> >>> The only thing which I'm still insecure is about attaching this to
> >>> phases, the difficulty seems that the super project doesn't need to
> >>> have this attached to any phase, and the dependency resolution fails
> >>> unless executed after install (a solution might be to split the parent
> >>> into a grand-parent providing the assembly descriptor and binding it
> >>> to phases in the intermediate parent). But I'm not sure anyway in
> >>> which phase to best create zip and tar.
> >>>
> >>> Cheers,
> >>> reto
> >>&
Re: assembly plugin and project inheritance
If you do something like
org.apache.maven.plugins
maven-dependency-plugin
*assembly-descriptor**<includeTypes>*
...**
copy-dependencies
That will only copy the assembly-descriptor dependencies of your module
On Sun, Feb 24, 2008 at 9:09 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
> Copy requires that the artifact must be in the local repository or in a
> remote repository.
>
> The copy dependencies allows for the artifact to come from the reactor, so
> you don't have to install the artifact into your local repository.
>
> The copy dependencies can be set to only copy one dependency.
>
> Trust me, this is the better way to do it.
>
> -Stephen
>
>
> On Sat, Feb 23, 2008 at 9:38 PM, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote:
>
> > Thank you very much for your help, I can now have many projects generate
> > the right assembly with just one assembly descriptor and without
> > requiring to check out multiple projects (and having them at the right
> > position in the directory structure).
> >
> > I don't understand your suggestion to use copy-dependencies, what I'm
> > doing is copying a single resource (the assembly descriptor) and not all
> > of the dependencies. The copy goal seems to do its job.
> >
> > Cheers,
> > reto
> >
> >
> >
> > Stephen Connolly wrote:
> > > there are two sets of goals in the maven dependency plugin.
> > >
> > > the first set are copy and unpack. you specify the artifacts inside
> > > the plugin configuration. these are not the set you want. the set you
> > > want are copy-dependencies (or something like that I am on my iPod so
> > > you will have to check) with this set you add the dependency to the
> > > pom. that will force maven to sequence things correctly for you.
> > >
> > > the build helper plugin has a default phase, so leave that alone. I
> > > would bind the dependency plugin to one of the generate phases
> > > (sources or resources)
> > >
> > > Stephen
> > > 2/22/08, Reto Bachmann-Gmür <[EMAIL PROTECTED]> wrote:
> > >
> > >> The version I posted doesn't work as the child-projects can't perform
> > >> the attach-artifact attached to the package phase.
> > >>
> > >> I've now extracted the dist configuration and the attachment of it to
> > a
> > >> separate project[1]. Having done this I also attached the copy and
> > the
> > >> assembly goals to the compile and package phases [2].
> > >>
> > >>
> > >> 1.
> > >>
> > http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps-assembly/trunk/pom.xml
> > >> 2. in
> > >>
> > http://knobot.svn.sourceforge.net/svnroot/knobot/rwcf-apps/trunk/pom.xml
> > >>
> > >>
> > >> Reto Bachmann-Gmür wrote:
> > >>
> > >>> Thanks Stephen,
> > >>>
> > >>> trying to follow the path you describe I added the following to the
> > >>> parent-pom:
> > >>>
> > >>>
> > >>> org.codehaus.mojo
> > >>> build-helper-maven-plugin
> > >>>
> > >>>
> > >>> attach-artifacts
> > >>> package
> > >>>
> > >>> attach-artifact
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> src/assembly/dist.xml
> > >>> xml
> > >>>
> > >>> assembly-descriptor
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> and
> > >>>
> > >>> org.apache.maven.plugins
> > >>> maven-dependency-plugin
> > >>>
> > >>>
> > >>>
> > >>> org.wymiwyg.rwcf
> > >>> rwcf-apps
> > >>> 0.0.1
> > >>> xml
> > >>> assembly-descriptor
> > >>> false
> > >>>
> > >>> ${project.build.directory}/src/assembly/
> > >>>
> > >>> dist.xml
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
Re: war directory exploded / how to do thi sin maven
We have developed a lot of web apps with Maven and IDEA.
The war plugin builds an exploded war file in target/${
project.build.finalName}
There is a configuration option for the war plugin that controls whether it
packages up the classes in the war module as a jar file and puts that in
WEB-INF/lib or leaves them as classes in WEB-INF/classes
As to the other dependencies, if they don't end up in WEB-INF/lib, how will
you know that your webapp works?
-Stephen
On Mon, Feb 25, 2008 at 10:12 PM, Marco Mistroni <[EMAIL PROTECTED]>
wrote:
> hello all
> @work, we are developing a web application using IntelliJ IDEA.
> we are not using maven, so structure of directory is as follows
>
> jsp (contains jsps and WEB-INF)
> src
> |__ java
> |__ test
>
> plus, we are launching tomcat from intelliJ, making tomcat point to the
> exploded directory jsp (in fact, the target-classes directory is
> jsp\web-inf\classes)
>
> we are using ant to build the app, which put all the classes in
> jsp\web-inf\classes. we have tomcat pointing to that directory so that
> every
> change in the jsp
> is immediately reflected on the browser.
>
> i wanted to move to maven, but i feel the directory structure imposed by
> maven will prevent me from doing what i am doing now.
> as example
>
> maven build a WAR in the target\ directory... .. so
> unless i 'hack' maven by
> specifying as target-classes directory the jsp\web-inf\classes, i'll
> have
> problems...
> also because in building war maven automatically add all the dependencies
> to
> web-inf\lib directory.
>
> i feel i cannot do that with maven unless i do some hacks
>
>
> has anyone ever end up in a similar situation?
>
>
> regards
> marco
>
Re: Problem with maven-dependency-plugin: copy-dependencies
Have you been doing a build clean?
If you don't do a clean build then artifacts from the previous build can end
up hanging around
-Stephen
On Tue, Feb 26, 2008 at 7:11 AM, amit kumar <[EMAIL PROTECTED]>
wrote:
> Hi,
> Now this is a new problem, I am seeing the dependency getting packaged as
> dependency-1.0.0-SNAPSHOT.jar as well as dependency-1.0.0-TIMESTAMP.jar
> I am using copy-dependency to copy the dependencies to a lib folder. How
> to
> overcome this?
>
> This is my configuration:
>
>
> ${project.build.directory}/${project.artifactId}-${
> project.version}/lib
> false
> false
> true
> true
>
>
> I tried turning true also but
> not
> working. Any help?
>
> Regards,
> Amit
>
>
> On Tue, Feb 26, 2008 at 12:29 PM, amit kumar <[EMAIL PROTECTED]>
> wrote:
>
> > Oh Ok. Thanks.
> >
> >
> > On Tue, Feb 26, 2008 at 4:33 AM, Brian E. Fox <[EMAIL PROTECTED]>
> > wrote:
> >
> > > The dependency plugin only copies things. It's up to whatever is doing
> > > the packaging to create the manifest.
> > >
> > > -Original Message-
> > > From: amit kumar [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, February 22, 2008 1:37 AM
> > > To: Maven Users List
> > > Subject: Re: Problem with maven-dependency-plugin: copy-dependencies
> > >
> > > Can I modify Manifest entries along with the copy-dependencies goal in
> > > configuration? Or something like that. I want the Manifest.mf to have
> > > entries for the copied dependencies(in the specific folder).
> > >
> > >
> > > Regards,
> > > Amit Kumar
> > >
> > > On Wed, Jan 2, 2008 at 2:18 PM, PatrickV
> > > <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >
> > > > The attachments are there. My first posting did indeed not include
> the
> > > > attachements, I edited the posting and now the file (pp.zip) is
> there.
> > > >
> > > >
> > > >
> > > > Brian E Fox wrote:
> > > > >
> > > > > The attachments didn't come through. Try writing a jira at
> > > > > http://jira.codehaus.org/browse/MDEP and attach the files there.
> > > > >
> > > > > -Original Message-
> > > > > From: PatrickV [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, January 01, 2008 11:08 AM
> > > > > To: users@maven.apache.org
> > > > > Subject: RE: Problem with maven-dependency-plugin:
> copy-dependencies
> > > > >
> > > > >
> > > > > I hope I can make it clear by attaching the pom's to this message.
> > > The
> > > > > poms
> > > > > are stripped versions of the real stuff.
> > > > >
> > > > > Module A = pp-common.xml
> > > > > Module B = pp-client.xml
> > > > > Module C = pp-server.xml
> > > > >
> > > > > The copy dependencies plugin is stated in pp-server.xml.
> > > > > pp-server depends on pp-common and pp-client.
> > > > >
> > > > > I expect to see after running the copy-dependency goal to target
> > > > > directory:
> > > > >
> > > > > pp-common.jar in target directory
> > > > > pp-client.jar in target directory
> > > > > all dependencies from pp-server
> > > > > all dependencies from pp-common not yet included in target
> directory
> > > > > all dependencies from pp-client not yet included in target
> directory
> > > > >
> > > > > What I do see in target directory
> > > > > all dependencies from pp-server
> > > > > all dependencies from pp-common
> > > > > all dependencies from pp-client
> > > > > BUT NOT... pp-common.jar and pp-client.jar, allthough they too ARE
> > > > > listed in
> > > > > the dependencies of the pp-server project.
> > > > >
> > > > > Packaging of pp-server (war or jar) has no influence on result.
> > > > >
> > > > > The process is triggered by executing mvn -U clean package on
> > > parent.
> > > > >
> > > > > I hope the issue is clear now.
> > > > >
> > > > > KR
> > > > >
> > > > > PatrickV
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brian E Fox wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> -Original Mes http://www.nabble.com/file/p14567676/pp.zip
> > > pp.zip
> > > > >> sage-
> > > > >> From: PatrickV [mailto:[EMAIL PROTECTED]
> > > > >> Sent: Sunday, December 30, 2007 2:11 PM
> > > > >> To: users@maven.apache.org
> > > > >> Subject: RE: Problem with maven-dependency-plugin:
> > > copy-dependencies
> > > > >>
> > > > >>
> > > > >>>I changed the packaging of module C into jar, and no difference.
> > > > >>>I think the copy-dependency plugin does not take into account
> > > > >> dependencies
> > > > >>>on artifacts on the reactor (in this case Module A and Module B),
> > > but
> > > > >> only
> > > > >>>on "real" dependencies from the repositorie.
> > > > >>
> > > > >> Not sure what you mean here. If a dependency is listed in the
> pom,
> > > it
> > > > > is
> > > > >> included. There are no other ways for dependencies to be
> included.
> > > > >> Sharing a reactor has other subtle effects but doesn't change the
> > > fact
> > > > >> that a dependency needs to be listed. Perhaps I'm not getting
> what
> > > > >> you're saying.
> > > > >>
> > > > >> "...I don't want to p
Re: war directory exploded / how to do thi sin maven
...
war
maven-war-plugin
<*archiveClasses>false***
On Tue, Feb 26, 2008 at 8:13 PM, Marco Mistroni <[EMAIL PROTECTED]> wrote:
> Stephen,
> thanks a lot! it was exactly what i was after
> any chances u can share your pom.xml?
>
> thanks in advance and regards
> marco
>
> On Tue, Feb 26, 2008 at 8:26 AM, Stephen Connolly <
> [EMAIL PROTECTED]> wrote:
>
> > We have developed a lot of web apps with Maven and IDEA.
> >
> > The war plugin builds an exploded war file in target/${
> > project.build.finalName}
> >
> > There is a configuration option for the war plugin that controls whether
> > it
> > packages up the classes in the war module as a jar file and puts that in
> > WEB-INF/lib or leaves them as classes in WEB-INF/classes
> >
> > As to the other dependencies, if they don't end up in WEB-INF/lib, how
> > will
> > you know that your webapp works?
> >
> > -Stephen
> >
> > On Mon, Feb 25, 2008 at 10:12 PM, Marco Mistroni <[EMAIL PROTECTED]>
> > wrote:
> >
> > > hello all
> > > @work, we are developing a web application using IntelliJ IDEA.
> > > we are not using maven, so structure of directory is as follows
> > >
> > > jsp (contains jsps and WEB-INF)
> > > src
> > > |__ java
> > > |__ test
> > >
> > > plus, we are launching tomcat from intelliJ, making tomcat point to
> the
> > > exploded directory jsp (in fact, the target-classes directory is
> > > jsp\web-inf\classes)
> > >
> > > we are using ant to build the app, which put all the classes in
> > > jsp\web-inf\classes. we have tomcat pointing to that directory so that
> > > every
> > > change in the jsp
> > > is immediately reflected on the browser.
> > >
> > > i wanted to move to maven, but i feel the directory structure imposed
> by
> > > maven will prevent me from doing what i am doing now.
> > > as example
> > >
> > > maven build a WAR in the target\ directory... ..
> so
> > > unless i 'hack' maven by
> > > specifying as target-classes directory the jsp\web-inf\classes,
> i'll
> > > have
> > > problems...
> > > also because in building war maven automatically add all the
> > dependencies
> > > to
> > > web-inf\lib directory.
> > >
> > > i feel i cannot do that with maven unless i do some hacks
> > >
> > >
> > > has anyone ever end up in a similar situation?
> > >
> > >
> > > regards
> > > marco
> > >
> >
>
Re: detected reference cycle, but there is no cycle conflict
AFAIK The scope does not matter as far as maven is concerned. This is a pom.xml cycle i.e. Maven does not know what order to examine the pom.xml files. The pom for A depends on the pom for B The pom for B depends on the pom for A In order to build the complete list of dependencies of A, it needs to know what dependencies of B will be added transitively If you "force" the issue, then the maven-release-plugin will never be able to build a release on it's own. -Stephen On Tue, Mar 4, 2008 at 1:04 PM, simim <[EMAIL PROTECTED]> wrote: > > > Jan Torben Heuer-3 wrote: > > > > Try to completely eliminate the "cyclic" reference by using an interface > > in > > A, so that you don't need to specifiy a dependency from B to A > > > > > > Jan > > > > thanks, but i think thats not a smooth solution in my case. at compilation > time there > is definitively not cycle, because B doesn`t need A in any way, at > compilation. > but maven abort the compilation with the message above. > > so, i see no problem at the design. i cannot understand why maven detects > there > an psoudo-cycle. maybe the relevant scope-option are not considered. > > maybe there is a possibility to set a "cycle-order" in maven? with that i > could set > reference A -> B before reference B -> A. maybe i can realize an order > with a common parent pom-file for A and B? perhaps that the wrong way? > > other ideas? thanks! > > -- > View this message in context: > http://www.nabble.com/detected-reference-cycle%2C-but-there-is-no-cycle-conflict-tp15825973s177p15826737.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: install:install-file via POM file
I would write a wrapper pom for installing your ear and use the build-helper plugin to attach the ear as an artifact to that wrapper pom.xml On Wed, Mar 5, 2008 at 2:11 AM, Wayne Fay <[EMAIL PROTECTED]> wrote: > As far as I know, you can't. > > Most people would simply write a shell script to deal with repeatedly > installing wars into a repo with different versions. > > Wayne > > On 3/4/08, gotama <[EMAIL PROTECTED]> wrote: > > > > > > How can I do: > > > > > mvn install:install-file > > > > not from the command line, but configured in a POM? > > > > I'd like to automate this as the EAR I am installing to the repo will > change > > frequently, but is not built w/ Maven. Until the module is Mavenized, I > > simply want a module POM to copy an EAR from a directory, say > > c:\deploy\version_3.0.1\app.EAR, version it using the parameter > specified in > > the POM and install it in the local/company repository. Once the module > has > > been Mavenized, I can tear this out and the parent POM will not know > that > > the module is now building with Maven. I basically want to create a > place > > holder POM for various modules which simply copies EARs from a location > and > > trick the parent POM into thinking its a regular Maven module. I don't > want > > to manually exec this on the command line because there are 15 EARs like > > this and 40 developers would have to do the same thing. I just want to > > automate this w/ "mvn" and be done. > > > > Thanks. > > > > > > -- > > View this message in context: > http://www.nabble.com/install%3Ainstall-file-via-POM-file-tp15841398s177p15841398.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] > >
Re: Unit Testing Hibernate/Entities/EJB3/EE (Req Advice)
Another unit test helper that you might find useful is https://easygloss.dev.java.net This is lightweight framework for injecting values into JavaEE annotated classes. It is not a replacement for the integration tests that you will be doing using OpenJPA, etc, but it can be useful for testing some of the more Unit Test type things that need to be tested. -Stephen On Wed, Mar 5, 2008 at 5:59 AM, David Blevins <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > Here is an example using OpenJPA/Entities/EJB3/EE. Specifically, an > @Stateful, injected EntityManager with EXTENDED persistence context, > and a JUnit TestCase. > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/injection-of-entitymanager/ > > This one is identical to the above but uses Hibernate instead of > OpenJPA: > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/jpa-hibernate/ > > This example is similar to the above two but uses an EntityManager > with TRANSACTION persistence context and shows how to run your test > code in a container controlled transaction. Could easily be updated > to use Hibernate instead (just switch the pom.xml with the above one > and swap the persistence.xml files). > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/testing-transactions/ > > I'm not really a believer in fake environments, especially when you > can get an equally lightweight, fast and easy to use EJB container > that's actually been incorporated in a Java EE 5 certified platform. > > Hope this helps! > > -David > > > On Mar 4, 2008, at 4:41 PM, Andrew Hughes wrote: > > > Hi All, > > > > This seems to be a hot topic at the moment, but there is very little > > documentation and references I can find... and so I'm asking for > > your help. > > > > *Background:* > > > > One of Maven's most brilliant functions is it's lifecycle's ability > > to slip > > straight into agile+continuous integration development (kudo's to > > maven). > > It's a wonderful thing that when you write your code and its unit > > tests > > today, that maven in many future versions and with countless changes > > will > > ensure your tests still work! If they don't maven will fail the > > build (I > > could go on but I wont)! So, the reason I'm really on this mailing > > list is > > because I want to utilize this wonderful practice! Manually unit > > testing and > > manually notifying people about error's is unreliable and so 2004! > > > > > > *So what do I want to test:* > > > > *Hibernate Entities:* > > > > I have an Entity data model that is provided by Hibernate maven > > modules. > > Each modules entities need to be unit tested. From what I have > > read.. the > > options available to perform this are Easygloss/mock, ejb3unit, > > OpenJPA, and > > TestNG. > > > > What I found so far (and don't take this as definitive): > > > > Easygloss/mock: This works a treat! Within my unit test's I can > > setup() an > > instance of a (Hibernate) entity manager and thus my Entities do > > persist. > > The unit tests are a little "cut and paste" the setup() into all of > > them, > > but as a whole you can't complain too much if it works. > > > > ebj3unit: This I found to be both brilliant and also non functional. > > I hope > > I am wrong, but I can't get this working with Hibernate. When I do > > run it > > against my entities I get all sorts of "Use of @OneToMany or > > @ManyToMany > > targeting an unmapped class" exceptions and problems with > > "@Embbeded" eta > > eta eta. Something which does not occur in easygloss, or when > > running the > > tests with ithin the JunitEE on the Application Server. What I can > > say is > > this is quite cool! The test classes you extent have some very neat > > default > > tests you should have run over your entity beans. Example would be, > > read a > > record x2 and see if both objects are .equals(). Other than the fact > > I can't > > get it working, it's greatest downfall is that I can't find a > > mailing list > > or irc channel or blog or wiki or anything to figure out what/if I > > am doing > > something wrong. From what I can see, it's brilliant... but I really > > need it > > working. > > > > OpenJPA: I am yet to use... but I can only assume this is pure JPA > > and not > > hibernate? Don't take my word for it though. > > > > TestNG : I am reading up on now, which looks good... but because Im > > greedy I > > do like the ejb3unit "default" tests and it will be hard to discard > > them. > > > > > > *EJB3:* > > As common moden architecture, you wrap your Entitie's with sensible > > "real > > world" operations on your data model (Entities). So lets say someone > > changes > > the @bean*, you want to make sure you don't effect anything else and > > you > > want to test it does persist and comes back out the other side. Now > > it gets > > a little complex, because not only do you need to mock the EJB* > > container > > for your session* beans. Because the beans depend on Entities, you > > will als
Re: dependency-copy
On Wed, Mar 5, 2008 at 6:16 AM, Saxena, Sandeep < [EMAIL PROTECTED]> wrote: > Thanks Upul. But it does not copy all transitive dependencies from a > list. > I want something like I give a list of 10 artifacts which may or may not > be > In the Project's POM and I want all transitive dependencies for these 10 > I think you will need to separate your concerns. When they are in the project's POM you should use copy-dependencies, when not in the project's POM you should use copy. If you have both, you will need to use both. > > Artifacts to be copied in a folder of my assembly. > > Thanks, > Sandeep. > > -Original Message- > From: Upul Godage [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2008 11:37 AM > To: Maven Users List > Subject: Re: dependency-copy > > I think assembly plugin does this. Here all the dependencies are copied > to a > lib directory in the final release. > http://maven.apache.org/plugins/maven-assembly-plugin/howto.html > > >bin > > > >lib > > > > > Hope this helps. > > Upul > > > On Wed, Mar 5, 2008 at 11:20 AM, Saxena, Sandeep < > [EMAIL PROTECTED]> wrote: > > > I want to copy all transitive dependencies for a list of artifacts in > my > > assembly. > > If I use "dependency: copy" with a list of artifacts I just get all > the > > jars defined > > In my list and not transitive dependencies. > > > > And if I use dependency: copy-dependencies, it takes all the artifacts > > from my project's POM > > Instead of taking a list of artifacts. > > > > To make it clear my project depends on three artifacts A, B and C but > I > > want to copy all the > > Transitive dependencies of another artifact D in a folder of my > > assembly. > > > > Any clues? > > > > Regards, > > Sandeep. > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Unit Testing Hibernate/Entities/EJB3/EE (Req Advice)
There I go reading things too fast! I thought you said EasyMock! I'm always glad to hear when somebody is using something I wrote! There is nothing stopping you from using it for more than just Entity/JPA/Hibernate OK, so the examples could do with some more work, but have a look at JavaEEGloss (If I recall correctly) It will call the @PostConstruct, @PreDestroy, etc. It also allows invoking the @AroundInvoke stuff though you do need to call them yourself. I should look at extending it to return a Proxy which calles the method interceptors for you! -Stephen On Wed, Mar 5, 2008 at 8:54 AM, Andrew Hughes <[EMAIL PROTECTED]> wrote: > Thanks David and Stephen > > Stephen, I am currently using EasyGloss, as noted in the review it works > very well But I believe it is limited to Entity/JPA/Hibernate eta > testing. > > David, cheers... tommorow I will give it a bash... > > night. > > > On Wed, Mar 5, 2008 at 7:19 PM, Stephen Connolly < > [EMAIL PROTECTED]> wrote: > > > Another unit test helper that you might find useful is > > > > https://easygloss.dev.java.net > > > > This is lightweight framework for injecting values into JavaEE annotated > > classes. It is not a replacement for the integration tests that you will > > be > > doing using OpenJPA, etc, but it can be useful for testing some of the > > more > > Unit Test type things that need to be tested. > > > > -Stephen > > > > On Wed, Mar 5, 2008 at 5:59 AM, David Blevins <[EMAIL PROTECTED]> > > wrote: > > > > > Hi Andrew, > > > > > > Here is an example using OpenJPA/Entities/EJB3/EE. Specifically, an > > > @Stateful, injected EntityManager with EXTENDED persistence context, > > > and a JUnit TestCase. > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/injection-of-entitymanager/ > > > > > > This one is identical to the above but uses Hibernate instead of > > > OpenJPA: > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/jpa-hibernate/ > > > > > > This example is similar to the above two but uses an EntityManager > > > with TRANSACTION persistence context and shows how to run your test > > > code in a container controlled transaction. Could easily be updated > > > to use Hibernate instead (just switch the pom.xml with the above one > > > and swap the persistence.xml files). > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/testing-transactions/ > > > > > > I'm not really a believer in fake environments, especially when you > > > can get an equally lightweight, fast and easy to use EJB container > > > that's actually been incorporated in a Java EE 5 certified platform. > > > > > > Hope this helps! > > > > > > -David > > > > > > > > > On Mar 4, 2008, at 4:41 PM, Andrew Hughes wrote: > > > > > > > Hi All, > > > > > > > > This seems to be a hot topic at the moment, but there is very little > > > > documentation and references I can find... and so I'm asking for > > > > your help. > > > > > > > > *Background:* > > > > > > > > One of Maven's most brilliant functions is it's lifecycle's ability > > > > to slip > > > > straight into agile+continuous integration development (kudo's to > > > > maven). > > > > It's a wonderful thing that when you write your code and its unit > > > > tests > > > > today, that maven in many future versions and with countless changes > > > > will > > > > ensure your tests still work! If they don't maven will fail the > > > > build (I > > > > could go on but I wont)! So, the reason I'm really on this mailing > > > > list is > > > > because I want to utilize this wonderful practice! Manually unit > > > > testing and > > > > manually notifying people about error's is unreliable and so 2004! > > > > > > > > > > > > *So what do I want to test:* > > > > > > > > *Hibernate Entities:* > > > > > > > > I have an Entity data model that is provided by Hibernate maven > > > > modules. > > > > Each modules entities need to be unit tested. From what I have > > > > read.. the > >
Re: Unit Testing Hibernate/Entities/EJB3/EE (Req Advice)
By the way, I have used EasyGloss with EasyMock to write unit tests for Stateless and Statefull session beans which use EJBs. The thing to remember is that they are unit tests! So I injected a mock EntityManager and other mock @Resource and @EJB references and I verify that the EJB under unit test calls interfaces with these mocks according to the contract. The functional tests tend to require some real objects, not just everything else is a mock, but again I found EasyGloss useful for these as at some point you need to push in Mocks, etc to force boundary tests. My integration tests always involve being deployed to a container, so at that point EasyGloss is not really useful (classloader rules and securtity permissions can get in the way) -Stephen On Wed, Mar 5, 2008 at 10:41 AM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > There I go reading things too fast! > > I thought you said EasyMock! > > I'm always glad to hear when somebody is using something I wrote! > > There is nothing stopping you from using it for more than just > Entity/JPA/Hibernate > > OK, so the examples could do with some more work, but have a look at > JavaEEGloss (If I recall correctly) It will call the @PostConstruct, > @PreDestroy, etc. It also allows invoking the @AroundInvoke stuff though you > do need to call them yourself. I should look at extending it to return a > Proxy which calles the method interceptors for you! > > -Stephen > > > On Wed, Mar 5, 2008 at 8:54 AM, Andrew Hughes <[EMAIL PROTECTED]> wrote: > > > Thanks David and Stephen > > > > Stephen, I am currently using EasyGloss, as noted in the review it works > > very well But I believe it is limited to Entity/JPA/Hibernate eta > > testing. > > > > David, cheers... tommorow I will give it a bash... > > > > night. > > > > > > On Wed, Mar 5, 2008 at 7:19 PM, Stephen Connolly < > > [EMAIL PROTECTED]> wrote: > > > > > Another unit test helper that you might find useful is > > > > > > https://easygloss.dev.java.net > > > > > > This is lightweight framework for injecting values into JavaEE > > annotated > > > classes. It is not a replacement for the integration tests that you > > will > > > be > > > doing using OpenJPA, etc, but it can be useful for testing some of the > > > more > > > Unit Test type things that need to be tested. > > > > > > -Stephen > > > > > > On Wed, Mar 5, 2008 at 5:59 AM, David Blevins <[EMAIL PROTECTED]> > > > wrote: > > > > > > > Hi Andrew, > > > > > > > > Here is an example using OpenJPA/Entities/EJB3/EE. Specifically, an > > > > @Stateful, injected EntityManager with EXTENDED persistence context, > > > > and a JUnit TestCase. > > > > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/injection-of-entitymanager/ > > > > > > > > This one is identical to the above but uses Hibernate instead of > > > > OpenJPA: > > > > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/jpa-hibernate/ > > > > > > > > This example is similar to the above two but uses an EntityManager > > > > with TRANSACTION persistence context and shows how to run your test > > > > code in a container controlled transaction. Could easily be updated > > > > to use Hibernate instead (just switch the pom.xml with the above one > > > > and swap the persistence.xml files). > > > > > > > > > > > > > > > > > http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/testing-transactions/ > > > > > > > > I'm not really a believer in fake environments, especially when you > > > > can get an equally lightweight, fast and easy to use EJB container > > > > that's actually been incorporated in a Java EE 5 certified platform. > > > > > > > > Hope this helps! > > > > > > > > -David > > > > > > > > > > > > On Mar 4, 2008, at 4:41 PM, Andrew Hughes wrote: > > > > > > > > > Hi All, > > > > > > > > > > This seems to be a hot topic at the moment, but there is very > > little > > > > > documentation and references I can find... and so I'm asking for > > > > > your help. > > > > > > > > > > *Background:* &
Re: dependency-copy
Sorry, my bad, I did not notice that dependency:copy does not have the option for transitive dependencies that copy-dependencies has Well I would refactor, have a module that has all the stuff you want as it's dependencies and use copy-dependencies to copy them, then archive them up into a zip or such. Then use unpack-dependencies on this zip in the module where you want them -Stephen On Wed, Mar 5, 2008 at 8:53 AM, Saxena, Sandeep < [EMAIL PROTECTED]> wrote: > I did not get this. They are not in my projects POM. If I use > Copy it just copies the artifacts in the list and not transitive > Dependencies. > > > > -----Original Message- > From: Stephen Connolly [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2008 2:21 PM > To: Maven Users List > Subject: Re: dependency-copy > > On Wed, Mar 5, 2008 at 6:16 AM, Saxena, Sandeep < > [EMAIL PROTECTED]> wrote: > > > Thanks Upul. But it does not copy all transitive dependencies from a > > list. > > I want something like I give a list of 10 artifacts which may or may > not > > be > > In the Project's POM and I want all transitive dependencies for these > 10 > > > > I think you will need to separate your concerns. > > When they are in the project's POM you should use copy-dependencies, > when > not in the project's POM you should use copy. > > If you have both, you will need to use both. > > > > > > Artifacts to be copied in a folder of my assembly. > > > > Thanks, > > Sandeep. > > > > -Original Message- > > From: Upul Godage [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 05, 2008 11:37 AM > > To: Maven Users List > > Subject: Re: dependency-copy > > > > I think assembly plugin does this. Here all the dependencies are > copied > > to a > > lib directory in the final release. > > http://maven.apache.org/plugins/maven-assembly-plugin/howto.html > > > > > >bin > > > > > > > >lib > > > > > > > > > > Hope this helps. > > > > Upul > > > > > > On Wed, Mar 5, 2008 at 11:20 AM, Saxena, Sandeep < > > [EMAIL PROTECTED]> wrote: > > > > > I want to copy all transitive dependencies for a list of artifacts > in > > my > > > assembly. > > > If I use "dependency: copy" with a list of artifacts I just get all > > the > > > jars defined > > > In my list and not transitive dependencies. > > > > > > And if I use dependency: copy-dependencies, it takes all the > artifacts > > > from my project's POM > > > Instead of taking a list of artifacts. > > > > > > To make it clear my project depends on three artifacts A, B and C > but > > I > > > want to copy all the > > > Transitive dependencies of another artifact D in a folder of my > > > assembly. > > > > > > Any clues? > > > > > > Regards, > > > Sandeep. > > > > > > > > > > > > > > > > - > > 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: dependency-copy
refactor your pom structure. If you originally had moduleA/ pom.xml (packaging jar) You refactor to something like moduleAsuper/ pom.xml (new pom with packaging pom) moduleA/ pom.xml (packaging jar - this is the old pom moved to a child) moduleB/ pom.xml (this is the dependency packaging pom) now when you do a mvn clean install from moduleAsuper it will do what you are looking for. Of course if you already have a directory-parent pom, I'd just add moduleB to that directory-parent (though it does mean that you have to do clean install from the directory-parent) Note: maven has two kinds of parent poms, the first kind is the one specified with the tag in the pom, the other kind is where the pom is in sub-directory. These do not have to be the same! (but for most people it helps if they are!) -Stephen On Thu, Mar 6, 2008 at 6:27 AM, sandeep28 <[EMAIL PROTECTED]> wrote: > > I want something like to run mvn clean install on my original POM and make > an > assembly which has all jars which I extracted using newly made POM. > > > sandeep28 wrote: > > > > Hi Stephen, I did that, I made a seperate POM with all desired artifacts > > and used copy-dependencies to take all transitive dependency in a new > > folder, but now how to include this > > new POM in my original POM. If I create a module in my original POM, > maven > > expects packaging type in aggregator POM as "POM" which is not possible > as > > I have to create a jar. HOw should I go beyond this. > > > > > > > > > > Stephen Connolly-2 wrote: > >> > >> Sorry, my bad, I did not notice that dependency:copy does not have the > >> option for transitive dependencies that copy-dependencies has > >> > >> Well I would refactor, have a module that has all the stuff you want as > >> it's > >> dependencies and use copy-dependencies to copy them, then archive them > up > >> into a zip or such. Then use unpack-dependencies on this zip in the > >> module > >> where you want them > >> > >> -Stephen > >> > >> On Wed, Mar 5, 2008 at 8:53 AM, Saxena, Sandeep < > >> [EMAIL PROTECTED]> wrote: > >> > >>> I did not get this. They are not in my projects POM. If I use > >>> Copy it just copies the artifacts in the list and not transitive > >>> Dependencies. > >>> > >>> > >>> > >>> -Original Message- > >>> From: Stephen Connolly [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, March 05, 2008 2:21 PM > >>> To: Maven Users List > >>> Subject: Re: dependency-copy > >>> > >>> On Wed, Mar 5, 2008 at 6:16 AM, Saxena, Sandeep < > >>> [EMAIL PROTECTED]> wrote: > >>> > >>> > Thanks Upul. But it does not copy all transitive dependencies from a > >>> > list. > >>> > I want something like I give a list of 10 artifacts which may or may > >>> not > >>> > be > >>> > In the Project's POM and I want all transitive dependencies for > these > >>> 10 > >>> > > >>> > >>> I think you will need to separate your concerns. > >>> > >>> When they are in the project's POM you should use copy-dependencies, > >>> when > >>> not in the project's POM you should use copy. > >>> > >>> If you have both, you will need to use both. > >>> > >>> > >>> > > >>> > Artifacts to be copied in a folder of my assembly. > >>> > > >>> > Thanks, > >>> > Sandeep. > >>> > > >>> > -Original Message- > >>> > From: Upul Godage [mailto:[EMAIL PROTECTED] > >>> > Sent: Wednesday, March 05, 2008 11:37 AM > >>> > To: Maven Users List > >>> > Subject: Re: dependency-copy > >>> > > >>> > I think assembly plugin does this. Here all the dependencies are > >>> copied > >>> > to a > >>> > lib directory in the final release. > >>> > http://maven.apache.org/plugins/maven-assembly-plugin/howto.html > >>> > > >>> > > >>> >bin > >>> > > >>> > > >>> > > >>> >lib > >>> > > >>> > > >>> > > >>> > > >>> > Hope this helps.
Re: override a goal within a phase
don't use jar and that will disable the jar:jar On Thu, Mar 6, 2008 at 12:10 PM, Paolo Casarini <[EMAIL PROTECTED]> wrote: > Hi, > > does anybody can tell me how can I replace the standard jar:jar, in > the package phase, with my :jar goal implemented by my Mojo? > or is there a way to disable the execution of the standard jar:jar goal? > > TIA, > Paolo. > -- > GPG key: 1024D/9C5AE886 2004-10-21 Paolo Casarini <[EMAIL PROTECTED]> > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: override a goal within a phase
You probably want to implement your own packaging type and have that packaging type apply the bindings you are after On Thu, Mar 6, 2008 at 4:14 PM, Martin Gainty <[EMAIL PROTECTED]> wrote: > Hi Stephen > > I had a similar situation present itself where I was building a mar > (essentially same as jar with a module.xml configurator) > so where the pom was specifying using mar i simply > changed the pom to use jar packaging e.g. jar > and this disables jar goals? > > This appears to be non-intuitive .. > > is there a readme which says to execute a goal specify the opposite on the > packaging element? > Any way to override packaging on command line? > Is there any documentation on this? > > Thanks/ > M- > - Original Message - > From: <[EMAIL PROTECTED]> > To: "Maven Users List" > Sent: Thursday, March 06, 2008 11:05 AM > Subject: Re: override a goal within a phase > > > > "jar" is the default value, so simply deleting the element is > > insufficient. You must actually change the value to something else, like > > "pom". > > > > > > Robert Egan > > > > Paolo Casarini <[EMAIL PROTECTED]> wrote on 03/06/2008 10:54:15 AM: > > > > > > > > I don't know... erasing jar don't change any > > > behaviour. The jar:jar goal is still invoked. > > > > > > Paolo. > > > > > > > > > Il giorno 06/mar/08, alle ore 16:42, Ian Hummel ha scritto: > > > > > > > Does that mean you will have to manually bind all the other goals to > > > > their respective phases? > > > > > > > > > > > > > > > > > > > > > > > > On Mar 6, 2008, at 7:37 AM, Stephen Connolly wrote: > > > > > > > >> don't use jar and that will disable the > > > >> jar:jar > > > >> > > > >> On Thu, Mar 6, 2008 at 12:10 PM, Paolo Casarini > > > >> <[EMAIL PROTECTED]> wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> does anybody can tell me how can I replace the standard jar:jar, > in > > > >>> the package phase, with my :jar goal implemented by my > Mojo? > > > >>> or is there a way to disable the execution of the standard jar:jar > > > >>> goal? > > --- > > This email message and any attachments may contain confidential, > > proprietary or non-public information. The information is intended > solely > > for the designated recipient(s). If an addressing or transmission error > > has misdirected this email, please notify the sender immediately and > > destroy this email. Any review, dissemination, use or reliance upon > this > > information by unintended recipients is prohibited. Any opinions > > expressed in this email are those of the author personally. > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Installing multiple files in the local repository using mvn install?
I've heard rumours about something called "shell scripts" or "batch files". According to the speculation that I've seen about these things, they would provide the ability you are looking for Unfortunately they are not XML files, so you have to learn a whole new syntax. Some of them start with "#!/bin/bash" while others start with "@echo off" and then they have a sort of stream of conciousness list of commands On Thu, Mar 6, 2008 at 4:22 PM, Krishnamurthi, Venkat < [EMAIL PROTECTED]> wrote: > > Hi, > > Is there a way to install multiple jars in the local repository using > the mvn install:install-file command? > > Thanks, > Venkat > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Maven / Repository / SVN
I know Kohsuke @ sun has a wagon that deploys to a svn server (as they run the sun maven2 repository off a svn repository) The advantage to storing a maven2 repository in svn is that mirroring becomes low on bandwidth, as svn update will only pull the changes since the last update where as rsync needs to determine the changes before it can send them. -Stephen On Tue, Mar 11, 2008 at 1:53 PM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > John Coleman schrieb: > >> the problem is that people here want to store artifact / > >> external libraries in svn rather than in an internal repository > >> > > > > These people have some bad thinking. There is simply no point putting > > guaranteed static objects into VCS, which is all about tracking changes. > > And since the POM defines all the dependencies and how they are used, > > and everything required for a build, then that mechanism is already > > ideal. > > > > If they are concerned about losing some artifacts, then they simply need > > to back them up, or provide some clustering. All you need to do is keep > > a mirrored server of your repo. > > > > > >> only thing i could think was to store the maven repository in > >> svn and check it out every time, pointing maven to look at > >> the localRepository in my custom directory > >> > > > > This is a "solution", but one to a problem that doesn't exist. Absurd. > > > > In my experience, this is a very common attitude though. > > For example, the jspwiki project currently under apache incubation > stores its dependencies in the version-control system and will not > change. And they are not stupid people; it is just the way they like to > work. > > In at least two previous jobs I have also tried to persuade people to > avoid storing deps in version-control and failed. So regardless of > whether it is right or wrong, it would be useful to have a way for maven > to deal with this. Persuading people to move to maven is difficult > enough without having to tackle a second problem like this concurrently. > > BTW, one of the issues is that previously java classpaths had to be set > up with the explicit names of dependent jars; having dependencies that > change names was awkward. So simply having a stable name, and > overwriting with later versions of the jars was tempting. Now that java > can use "*" to pick up all jars in a dir this is no longer relevant, but > the habit endures. > > I think that in this case, storing the repository in VCS makes sense. > Ideally you would have a webserver acting as a repository which receives > svn commit messages for the repo directory and automatically updates its > dir, so that commits of new jars are visible immediately. > > I think your suggestion of pointing maven at a locally-checked-out > repository tree is also possible I think; hopefully "file://" is > supported as a repository base url. > > Cheers, > Simon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Maven / Repository / SVN
On Tue, Mar 11, 2008 at 2:29 PM, Graham Leggett <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > For example, the jspwiki project currently under apache incubation > > stores its dependencies in the version-control system and will not > > change. And they are not stupid people; it is just the way they like to > > work. > > The core problem is one of disk space - storing artifacts in source > control means that there is no way to ever recover the artifacts used > should you want to clean out and archive old versions. > But then you would be breaking the old builds and bye-bye reproducibility! I don't see anyone purging repo1.maven.org anytime soon. I agree for a SNAPSHOT repository, using a SVN backing store is a "bad thing" For a release repository, using a SVN backing store is not that bad, as only the metadata changes > > Usually getting the development teams to explain their "store artifacts > in source control" position to the people who provide the budget for the > disk space usually solves this problem. > > Regards, > Graham > -- >
Re: Filtering Javadoc overview.html and package.html
You need to have the filtering bound to the generate-sources phase of the
build lifecycle. AFAIK filtering is bound to a phase after the phase that
javadoc requires, so it will not get invoked.
I would put your javadocs in a third folder: src/main/javadoc
I would bind an additional execution of the resources plugin to the
generate-sources phase that copies and filters the javadocs from
src/main/javadoc to target/generated-sources/javadoc
And finally I would bind an execution of the buildhelper-maven-plugin (at
mojo.codehaus.org) to the generate-sources phase as well that adds
target/generated-sources/javadoc as an additional source path.
This will result in the filtering of (only) the javadocs occurring during
the generate-sources phase as well as defining the filtered javdocs as being
source code. When the javadoc plugin runs it looks for these files in the
defined source directories (which is what the buildhelper plugin will be
adding)
-Stephen
On Wed, Mar 12, 2008 at 1:50 AM, Andrew Hughes <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I am trying to filter the overview.html and package.html javadoc
> resources.
> Specifically, it is worthwhile inserting the ${project.description} and ${
> project.version} and maybe even some other information like the SCM, Issue
> Tracking, information within the Javadocs. I have selected the non-default
> location for these files within the src/main/java location. Why, because
> if
> someone renames a package/directory... then the code and doco diverge. The
> filter below does not work, but it does work if I apply this to the
> src/main/resources directory.
>
> How do I filter the Javadoc files when generating the javadocs?
>
>
>
>
>src/main/java
>true
>
>**/*.html
>
>
>
>
>
> Much Appreciated!!!
>
> Andrew
>
Re: How to disable maven-compiler-plugin for jar packaging
I think you are out of luck. What is the other plugin that breaks, and does the hk2-jar packaging produce artifacts that have the type hk2-jar or do they have the type jar? I suspect that this bold 3rd plugin is expecting artifacts of type jar and you are producing artifacts of type hk2-jar which is why it breaks. I remember that there is a way to have the packaging xyz still produce only artifact of type abc, and that using this removed the issue you describe when I encountered it before -Stephen On Wed, Mar 12, 2008 at 8:46 AM, Sahoo <[EMAIL PROTECTED]> wrote: > Hi, > > I have an unusual requirement where I want to replace > maven-compiler-plugin by another compiler-plugin. Is there a way I can > do this? My situation is like this: > I want to use hk2-maven-plugin [1] as the compiler plugin. This plugin > automatically executes if I change my project's packaging type to > hk2-jar, but I don't want to change the project's packaging type from > jar to hk2-jar, as I depend on some other plugin which stops working > when I change my packaging type. If I just add an execution entry for > hk2-maven-plugin:compile goal, it is useless as all the sources first > get compiled using the default compiler-plugin. One option might be to > call hk2-maven-plugin in a pre-compile phase, but is that the only > option to disable the default plugin? I am looking for some ideas here. > > Thanks, > Sahoo > > [1] https://hk2.dev.java.net/hk2-maven-plugin/hk2-compile-mojo.html > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Deploy to multiple oc4j instances
On Tue, Mar 11, 2008 at 10:58 PM, Chris Russell <[EMAIL PROTECTED]> wrote: > Hello, > > I've had good success deploying my application to a single oc4j instance > using 'mvn install'. > Sounds like you're using a sledge-hammer to crack a peanut. There are at least three lifecycles in maven: build, clean, and site. The clean lifecycle has only one phase: "clean" The reporting lifecycle has two phases: "site" and "site-deploy" The build lifecycle has many phases: "validate", "compile", "test", "package", "install", and "deploy" are just some of the well known ones. When you specify a phase as a goal for the maven command, maven will invoke all of the previous phases in the lifecycle. The ... section in the pom defines the default binding of plugins to phases in the lifecycles, and you can add bindings of other plugins to phases using the and sections of the pom. When binding a plugin to a lifecycle phase it helps to understand what the different phases are designed to achieve: The "package" phase of the build lifecycle is designed to package up the artifact that you have built. The "install" phase of the build lifecycle is designed to install the packaged artifact into your local maven repository cache. The "deploy" phase of the build lifecycle is designed to deploy the packaged artifact to it's remote maven repository. I said that I thought you were using a sledge-hammer to crack a peanut because what I fear you are doing is configuring the maven-install-plugin to copy the packaged artifact to your oc4j server _instead of_ the local maven repository cache. That would be a bad thing as now any other maven projects that depend on your artifact will fail their builds. I hope that what you have done is bind another plugin to the install phase so that the artifact still ends up in the local maven repository cache. That would be less bad. However, what I would do would be something completely different. I would not bind the plugin you are using to copy the packaged artifact to any phase at all, I would just invoke that plugin directly. Then I could use profiles to configure that plugin for each of the servers that it will be deploying to. For example, if I was using the antrun plugin, I would have profiles that define the deploy locations for each of the oc4j servers that I want to deploy to (or if that's just an url, I'd use a command line property) then I could do mvn install which would package up the artifact and install it into the local repository followed by mvn antrun:run -PtestServer if I was using profiles or mvn antrun:run -Doc4jDeployUrl=... I could even do both in one go: mvn install antrun:run -PtestServer If you really want to bind the plugin to the install phase, I would do that in the profiles using unique execution id's, that way you could just specify all the profiles for the servers to deploy to, for example mvn install would just install to local repository while mvn install -PdevServer -PtestServer would install to local repo, development server and test server! -Stephen
Re: Forcing the execution of a phase before a goal
I think you need an annotation something like @requires-phase=compile I just cannot remember the exact annotation you require. Also don't do this in conjunction with @aggregator! -Stephen On Wed, Mar 12, 2008 at 3:52 PM, carioca <[EMAIL PROTECTED]> wrote: > > Hi, > > In my plugin I have a goal that is invoked manually: > > mvn os:my-goal > > The goal is invoked from the master project directory of a multi module > project. > I would like to force the compile phase before my goal is invoked. > It should be like invoking the following command line: > > mvn compile os:my-goal // this works > > In order to do that I added the following annotation to the goal's Mojo: > > /** > * @goal my-goal > * @execute phase=test-compile > */ > > This suppose to force the execution of the lifecycle untill the > test-compile > phase before the Mojo is executed. > It works when running the goal from a sub module with packaging=jar; It > doesn't work when invoking the goal from the master project directory > (packaging=pom). > > Instead I get the following message: > > No goals needed for project - skipping > > and my goal is invoked immediatelly. > > I guess I'm doing something wrong. > Can anyone help? > > Thanks, > Shai > -- > View this message in context: > http://www.nabble.com/Forcing-the-execution-of-a-phase-before-a-goal-tp16005279s177p16005279.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 Practice for IDL, WSDL, etc.?
have the WSDL in it's own module and then have the server and client depend on the WSDL On Wed, Mar 12, 2008 at 9:21 PM, SingleShot <[EMAIL PROTECTED]> wrote: > > We have a large number of language-independent interface files, mostly IDL > and WSDL. We use these files to generate java, both for the client side > and > server side. What's different about these kinds of source files from the > traditional .java source file is that they generate two sets of output > (client and server). We want these two sets of output to be packaged in > separate JARs so users of a service only need to have the client JAR and > its > transitive dependencies, not the server JAR and all of its transitive > dependencies. > > So, what is the best practice for this kind of setup? I believe these are > the options available to me: > 1) Create a single module and have it package both the client and server > into a single JAR. > 2) Create a single module and have it generate two JARs. This can be done > by > defining an additional execution on the JAR plugin. Have each JAR > configuration filter for either client or server classes. > 3) Create two modules, one for creating a client JAR, and one for creating > a > server JAR. Set up each module to share a common source directory (where > the > IDL files live). > > I won't do option (1) because users must depend on too much that is > unnecessary. I won't do option (2) because both artifacts share the same > dependencies (since they are defined by the same POM), thus users end up > depending on too much anyway. Option (3) seems most promising, but then > what > is the best practice for multiple modules sharing the same source > directory? > > Thanks, > > Mike > -- > View this message in context: > http://www.nabble.com/Best-Practice-for-IDL%2C-WSDL%2C-etc.--tp16012616s177p16012616.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: Findbug's Maven2 Plugin future direction
However, I would add a check that won't try and run findbugs if maven is started with jdk 1.4... have it instead print diagnostic information or a friendly error message to let people know that JDK 5.0 is required or else that they should use the 1.2 branch version On Fri, Mar 14, 2008 at 8:58 AM, Rémy Sanlaville <[EMAIL PROTECTED]> wrote: > I agree with Dan. It's better to keep a branch for the jdk 1.4 in case for > legacy systems. I f we found a bug in the plugin it's better to be able to > load a jira and fix it. > > +1 to use Findbugs 1.3.x and require Java 5 to run for the trunk > > Rémy > > 2008/3/14, Dan Tran <[EMAIL PROTECTED]>: > > > > last one > > > > release 1.2, branch it, > > > > then release 2.0 on trunk > > > > > > -D > > > > >
RE: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
frodesto wrote: > > > Jörg Schaible wrote: >> >> >> Why is it a problem for you, that it is available in the classpath for >> the test? >> >> - Jörg >> >> > > Hi again. I see your point in that in many (most?) cases you actually > would like the artifacts with scope 'provided' to be available in the > classpath for the unit tests. > > However, in my case this causes problems since the javaee-api.jar cannot > be used at runtime. It only provides the interface part of the Java EE > APIs, but no implementation. If you try to use it at runtime, you will get > java.lang.ClassFormatError and other weird exceptions. You have to use a > "real" JavaEE implementation at runtime. > > In my case I am using the javaee-api to get access to the JMS API > (javax.jms). I need the API classes to get my code to compile, but I > cannot include this jar as a compile-time dependency since the > app-server/JMS provider will provide the "real" JMS implementation. > > I my unit tests I need a "real" JMS implementation, and I am using > ActiveMQ. ActiveMQ also bundles the javax.jms package, and this is the > one I need to use at test-time. I have included the ActiveMQ jar as > scope="test" dependency. When I run the unit tests, I get a classpath with > two different versions of the javax.jms package (a "dummy implementation" > in javaee-api.jar and a real one in activemq-core.jar), and unfortunately > it seems like the JVM chooses the wrong one. > > I need a way to make Surefire skip the javaee-api.jar from the test-time > classpath or a way to control which version the JVM will use. > > Frode > > See http://forums.java.net/jive/thread.jspa?threadID=28648&tstart=0 In my opinion, it is that the javaee-api.jar that is being used is borked. (At least in terms of use cases with Maven) In the interim, I suggest changing from using the javaee-api.jar with scope provided to using the individual jsr spec api jars with scope provided. (As the individual spec jars do not seem to be borked) -Stephen. -- View this message in context: http://www.nabble.com/Surefire-includes-artifacts-with-scope-%27provided%27-in-the-runtime-classpath%2C-is-this-correct--tf4016962s177.html#a11662554 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: Surefire includes artifacts with scope 'provided' in the runtime classpath, is this correct?
frodesto wrote: > > In my case I am using the javaee-api to get access to the JMS API > (javax.jms). I need the API classes to get my code to compile, but I > cannot include this jar as a compile-time dependency since the > app-server/JMS provider will provide the "real" JMS implementation. > > I my unit tests I need a "real" JMS implementation, and I am using > ActiveMQ. ActiveMQ also bundles the javax.jms package, and this is the > one I need to use at test-time. I have included the ActiveMQ jar as > scope="test" dependency. When I run the unit tests, I get a classpath with > two different versions of the javax.jms package (a "dummy implementation" > in javaee-api.jar and a real one in activemq-core.jar), and unfortunately > it seems like the JVM chooses the wrong one. > Most likely is that the javax.jms references one of the classes which should be provided by the container (which it has to pull from javaee-api.jar, which is borked, which causes a classloader error, which [i'm guessing] causes your problem) -- View this message in context: http://www.nabble.com/Surefire-includes-artifacts-with-scope-%27provided%27-in-the-runtime-classpath%2C-is-this-correct--tf4016962s177.html#a11662736 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: Multiple source tree in maven 2
have a look at the buildhelper-maven-plugin at org.codehaus.mojo it has the ability to add multiple source paths the "right" way rather than your hack Sent from my iPod On 15 Mar 2008, at 16:55, "Cyril Ledru" <[EMAIL PROTECTED]> wrote: Hi, I had this problem earlier trying to migrate from ant. I had sources in src/java and src/util. What I did is put the to src and put includes and excludes in the maven-compiler-plugin configuration. So for you it would be modules in sourceDirectory and then x/src/**/*.java y/src/**/*.java z/src/**/*.java in the element of maven-compiler-plugin. The only problem I have so far is that doing mvn eclipse:eclipse result in having only src as source directory so I have to edit my eclipse build path by hand. Having said that I must add that I'm a maven newby and that there's maybe a better way to do it. Cyril. On Sat, Mar 15, 2008 at 5:21 PM, david.delbecq <[EMAIL PROTECTED]> wrote: Hello, am trying to mavenize an existing ant based projet. One of the caracteristics of the project is it's source tree organization modules/x/src/... modules/y/src/... modules/z/src/... I thought first of using maven modules for this, but the dependency graph makes it impossible (x depends on y which depends on z which depends on x, it's just an example). The current ant task just build all modules at same time in a single jar. So we'd like to make that too with maven2 (the mavenization should not imply a code reorg, whe just want that project to provide a pom + jar + dependencies informations). I tried to put multiple entries, but maven complains there can be only one. Anyone has a suggestion on how to put multiple tree in compilation? It seems possible to put multiple resource trees, but not multiple source trees? Maybe using the generate-source goal and some copy goals, someone has suggestions? - 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: What is the reactor?
On Wed, Mar 19, 2008 at 9:11 AM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > Hi, > > There was recently a question on this list about how to implement an odd > build order for submodules in a multi-module project. I said that it > wasn't possible, but Brian corrected me and said that in fact it is > automatic. > > So after some pondering, I have come to the following conclusion. Can > someone confirm if I have this right? > > When maven is executed against a pom that has tags, then maven > gathers together the poms for all the referenced modules, and their > submodules etc. into a big pool of poms. The dependencies for each pom > are checked, and the list of poms is reordered so that they are sorted > in the necessary order, regardless of where the modules are in the > directory structure. This process is called "the reactor". > > Then whatever command the user requested is applied over this reordered > list of poms. > > Is that correct? In essence, yes > And is that all the "reactor" does? > > And (back to the original poster's question) can the order be affected > by profiles, ie if dependencies are altered depending on what profiles > are currently active, does the reactor take that into account? Yes, if a profile adds dependencies or even additional modules, those will be taken into account. Additionally, the order can also be affected because if a plugin which is an "aggregator" plugin is bound to a phase that will be executed. An aggregator plugin is supposed to be executed only in the root pom, _after_ all the other plugins have completed execution. However, this is not quite how things work at present, and you can end up with a badly broken build if you carelessly add @aggregator plugin goals to your build. > > Thanks, > Simon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: A "provide" mecanism for poms?
well I would have jsf-api as scope=provided I would not depend on jsf-impl You will be deploying this application to a container that provides the api and it's impl. You should not be depending on any of the impl classes, so that would be my logic. If you then have customers that want to deploy to a container that does not supply a JSF impl, you could have assembler produce two distributions for these customers: 1. with the JSF-api and JSF-impl 2. with the myfaces-api and myfaces-impl On Wed, Mar 19, 2008 at 9:32 AM, David Delbecq <[EMAIL PROTECTED]> wrote: > Hello maven users, > > I encountered a curiosity in our maven dependency graph, while trying to > find out why our webapp was failing. > > What is the suggested and most proper solution when a library X and a > library Y are "providing" the same api. > The suggested and most proper solution is to have only one api.jar and have multiple impl.jar's Depending on the container rules for your api you would either have the api as scope=compile or scope=provided. The impl.jar's should all have a scope=compile dependency on the standard api.jar I would not have any dependency on the impl.jar (unless I needed it for unit tests, in which case scope=test) > > Am using myfaces api and myfaces impl. Both are implementation > respectively of the jsf-api and jsf-impl of sun. However, a few jsf > based library are marked as depending on jsf-api and jsf-impl. Is there > some way to tell maven that myfaces-api and myfaces-impl are the same as > jsf-api and jsf-impl and, as such, that if it encounter jsf-api or > jsf-impl in the dependencies transitivity, it should not take that into > consideration cause myfaecs was used higher in the graph? I could use > restriction, but since the dependency to jsf can go deep in the graph > using several path, with pom will be bloated with ... > There are quite a good amount of sun tools that have an equivalent > counter-part in apache project i think. > > -- > David Delbecq > Institut Royal Météorologique > Ext:557 > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Running two builds of the same branch simultaneously
On Thu, Mar 20, 2008 at 3:36 AM, Dan Fabulich <[EMAIL PROTECTED]> wrote: > Brian E. Fox wrote: > > >> Samuel Le Berrigaud wrote: > >> > >>> 1. only run mvn verify, this way nothing gets installed into the local > >>> repository, > >> > >> This doesn't work in a multi-module reactor build where the modules > >> depend on each other, does it? > > > No, it will only work if you at least do compile (then a reference to > > /target/classes is passed instead of the jar) > > Huh? verify is after compile, right before install. (Actually, I did > "package", then later tried "verify" to see if it would work; neither > did.) Should that have worked? > > -Dan > Are you using maven-dependency-plugin at all? if you are then you should be using the "copy-dependencies" or "unpack-dependencies" goals and not the "copy" or "unpack" goals for those dependencies that come from the reactor, otherwise the build will fail as you describe -Stephen
Re: Running two builds of the same branch simultaneously
You could do even better! in X create mvn.bat that is just @echo off %MAVEN_HOME%\bin\mvn.bat -s %USERPROFILE%\.m2\settings-x.xml %* create mvn.sh that is just #!/bin/sh $MAVEN_HOME/bin/mvn -s ~/.m2/settings-x.xml $* in Y create mvn.bat that is just @echo off %MAVEN_HOME%\bin\mvn.bat -s %USERPROFILE%\.m2\settings-y.xml %* create mvn.sh that is just #!/bin/sh $MAVEN_HOME/bin/mvn -s ~/.m2/settings-y.xml $* Now whichever window you are in, running mvn or ./mvn.sh will use the correct settings.xml and will not require remembering which command to launch from which window. You can even check these batch and shell scripts into SCM so that the release plugin will not complain about them. -Stephen P.S. you could make them even more portable by having them check for the settings-x.xml and settings-y.xml and reverting to defaults if those settings are not present On Thu, Mar 20, 2008 at 7:47 AM, Wayne Fay <[EMAIL PROTECTED]> wrote: > You could do the following... > > Copy ~/.m2/settings.xml to ~/.m2/settingsy.xml > Configure localRepository in settingsy.xml to point "somewhere else" > > Copy MAVEN_HOME/bin/mvn.bat to mvny.bat > Edit mvny.bat and append "-f ~/.m2/settingsy.xml" to the call to mvn > > Then call normal "mvn" from X, and mvny from Y. This will > automatically use the 2 localRepositories without messing with poms or > logging in as 2 users etc. You just have to remember to use mvn in one > window and mvny in the other. > > Wayne > > On 3/19/08, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > Brian E. Fox wrote: > > > > >> Samuel Le Berrigaud wrote: > > >> > > >>> 1. only run mvn verify, this way nothing gets installed into the > local > > >>> repository, > > >> > > >> This doesn't work in a multi-module reactor build where the modules > > >> depend on each other, does it? > > > > > No, it will only work if you at least do compile (then a reference to > > > /target/classes is passed instead of the jar) > > > > Huh? verify is after compile, right before install. (Actually, I did > > "package", then later tried "verify" to see if it would work; neither > > did.) Should that have worked? > > > > -Dan > > > > - > > 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: Problem with Maven making internet connection drop out
Does the same thing happen when building Hudson? Hudson has such a mad collection of dependencies that it should cause the same issue for you IMHO. -Stephen On Fri, Mar 21, 2008 at 7:54 AM, Wim Deblauwe <[EMAIL PROTECTED]> wrote: > Hi, > > I have a problem with running the Atlassian PDK. They use Maven 2. See > > http://confluence.atlassian.com/display/DEVNET/How+to+Build+an+Atlassian+Pluginfor > their instructions. > > When I try to run mvn idea:idea, everything seems to work for a while, but > then in the midst of the work being done, my internet connection drops > out. > I can restore the connection by doing ipconfig /renew. The behaviour is > very > consistent with running the maven command. I did not run the command for a > few hours and my internet connection was fine, then everytime I try run > mvn > idea:idea, it fails. Running mvn -Pplugin-debug works fine, I got a > running > JIRA instance with an empty plugin. > > I'm working on Windows XP. Anybody experienced a simular problem? I > suspect > that maybe the many, many dependencies have something to do with it? > > regards, > > Wim >
Re: Problem with Maven making internet connection drop out
it's on cvs On Fri, Mar 21, 2008 at 8:23 AM, Wim Deblauwe <[EMAIL PROTECTED]> wrote: > I will try, what is the svn url? > > 2008/3/21, Stephen Connolly <[EMAIL PROTECTED]>: > > > > Does the same thing happen when building Hudson? > > > > Hudson has such a mad collection of dependencies that it should cause > the > > same issue for you IMHO. > > > > -Stephen > > > > On Fri, Mar 21, 2008 at 7:54 AM, Wim Deblauwe <[EMAIL PROTECTED]> > > wrote: > > > > > > > Hi, > > > > > > I have a problem with running the Atlassian PDK. They use Maven 2. See > > > > > > > > > http://confluence.atlassian.com/display/DEVNET/How+to+Build+an+Atlassian+Pluginfor > > > their instructions. > > > > > > When I try to run mvn idea:idea, everything seems to work for a while, > > but > > > then in the midst of the work being done, my internet connection drops > > > out. > > > I can restore the connection by doing ipconfig /renew. The behaviour > is > > > very > > > consistent with running the maven command. I did not run the command > for > > a > > > few hours and my internet connection was fine, then everytime I try > run > > > mvn > > > idea:idea, it fails. Running mvn -Pplugin-debug works fine, I got a > > > running > > > JIRA instance with an empty plugin. > > > > > > I'm working on Windows XP. Anybody experienced a simular problem? I > > > suspect > > > that maybe the many, many dependencies have something to do with it? > > > > > > regards, > > > > > > Wim > > > > > >
Re: Multiple Jars
You don't have to install it in your local repository On Sun, Mar 23, 2008 at 12:26 AM, Trenton Adams <[EMAIL PROTECTED]> wrote: > Hi Wendy, > > Thanks for the suggestion. > > Yes, I am aware of that, but that is precisely what I am trying to > avoid. I don't want to make things more complex, by having a multiple > step deployment process. I want "simple". I want simple, primarily > because maven has been simple up until this point, and it has condition > me to want that. Is there a way to make this simpler? > > For instance, when I'm developing, I use ant to deploy automatically to > my webapp folder in tomcat. Tomcat has "reloadable=true", which > automatically reloads my classes. So, doing it the way you describe > makes me have to do multiple steps as follows... > 1. Install my JAR in the local repository > 2. Create a WAR > 3. Use a shell script (or ant) to install under my webapp folder in > tomcat. Nope, from the parent pom.xml you do mvn package That will build the jar and the war (using the jar that was just built) if you add either the tomcat maven plugin or cargo maven plugin to the war module and bind it using a profile (with id="i_am_developing") to the package phase you can even do mvn package -Pi_am_developing then you can use that one command to build everything and deploy to your tomcat instance locally Oh and nothing has gone into the local or remote repository! > > With Ant, I had the following steps. > > 1. run "ant dist" > > Now, if maven can't do what I'm desiring, then I rest my case about it > being more complex in "some" circumstances. And that's fine, but I just > wanted to try and get the work done with "one" tool rather than two. > But, if I use maven just for dependency resolution, and release > management, that will have some added benefit, just not as much as I had > hoped. > > Thanks for the suggestion though. :) Perhaps I'll try and get on the > IRC as you suggest. > > Thanks Wendy. > > Wendy Smoak wrote: > > On Sat, Mar 22, 2008 at 5:02 PM, Trenton Adams <[EMAIL PROTECTED]> > wrote: > > > > > >> Dependencies pull from a remote repository. I don't want to pull from > a > >> remote repository, I want to pull from modules themselves (locally), > >> into a combined WAR. > >> > > > > Maven is repository based, true, but it first looks in its local > > repository. If you build something locally with 'mvn install' it will > > be available in the local repo (usually ~/.m2/repository). > > > > So, 'mvn install' your jar, then declare a dependency on it from your > > webapp module. > > > > The next step is adding a parent pom that lists your jar and webapp as > > modules, so you can build it all at once. > > > > There's usually someone around on #maven (there's a web interface to > > it at http://irc.codehaus.org) if you need help. > > > > > >
Re: cobertura + surefire config
beware. we have had tests that pass when instrumented with cobertura, but fail when run normally. this is at least one reason why what you are trying to do is "a bad thing" - Stephen Sent from my iPod On 25 Mar 2008, at 16:13, "Brian Relph" <[EMAIL PROTECTED]> wrote: Hello, I was wondering if someone could help me fix my surefire + cobertura config. I only want one unit tests to run ONE time, but when I add the cobertura-maven-plugin to the reporting section, it seems to trigger another surefire:test phase. Any help? Here is my current config: org.codehaus.mojo cobertura-maven-plugin 2.2 site pre-site clean instrument site instrument cobertura org.apache.maven.plugins maven-surefire-plugin 2.3.1 once net.sourceforge.cobertura.datafile target/cobertura/cobertura.ser ... org.apache.maven.plugins maven-project-info-reports-plugin 2.0.1 dependencies cim project-team summary issue-tracking scm index org.apache.maven.plugins maven-surefire-report-plugin 2.4.2 report-only org.codehaus.mojo cobertura-maven-plugin 2.2 ... -- Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cobertura + surefire config
1. Tests that verify multiple thread behaviour. as cobertura will effectively synchronize the threads in order to record the code coverage. 2. Tests that verify performance. 3. One system had a bug whereby the server we were communicating with would read the message header from the stream and then block until the next packet (the body) was sent. when instrumented the two packets were sent by our client due to instrumentation adding enough of a delay. when running in the real world communication did not work as they were sent as a single packet. NOTE: in all cases the issues identified were real issues. and the fact that the results differed between instrumented and uninstrumented caused us to find these bugs. I have similar stories where tests passed uninstrumented and failed instrumented. IMHO, you need to run them twice on more than one JVM! - Stephen Sent from my iPod On 25 Mar 2008, at 18:08, "Wayne Fay" <[EMAIL PROTECTED]> wrote: Can you provide details for one or two of them? I'd like to know what to look out for in the future. Wayne On 3/25/08, Stephen Connolly <[EMAIL PROTECTED]> wrote: beware. we have had tests that pass when instrumented with cobertura, but fail when run normally. this is at least one reason why what you are trying to do is "a bad thing" - Stephen Sent from my iPod On 25 Mar 2008, at 16:13, "Brian Relph" <[EMAIL PROTECTED]> wrote: Hello, I was wondering if someone could help me fix my surefire + cobertura config. I only want one unit tests to run ONE time, but when I add the cobertura-maven-plugin to the reporting section, it seems to trigger another surefire:test phase. Any help? Here is my current config: org.codehaus.mojo cobertura-maven-plugin 2.2 site pre-site clean instrument site instrument cobertura org.apache.maven.plugins maven-surefire-plugin 2.3.1 once net.sourceforge.cobertura.datafile target/cobertura/cobertura.ser ... org.apache.maven.plugins maven-project-info-reports-plugin 2.0.1 dependencies cim project-team summary issue-tracking scm index org.apache.maven.plugins maven-surefire-report-plugin 2.4.2 report-only org.codehaus.mojo cobertura-maven-plugin 2.2 ... -- Brian - 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: cobertura + surefire config
And while ANT lets you make that mistake, I would encourage you to run the tests twice and you will have greater assurance that your code is correct if it passes instrumented and uninstrumented. (Better assurance still is to run with BEA, IBM and Sun's JVMs on both single core and multi-core machines, with linux and windows as the OS) - You kinda need Hudson's matrix projects to run those boys for you though!) -Stephen On Tue, Mar 25, 2008 at 4:54 PM, Trevor Torrez <[EMAIL PROTECTED]> wrote: > As far as I am aware this is a known issue with no resolution. > > Perhaps we can get the cobertura plugin to expose a report-only goal > and always do instrumentation for the tests. That was the approach I > used to use with ant. > > > On Tue, Mar 25, 2008 at 12:13 PM, Brian Relph <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I was wondering if someone could help me fix my surefire + cobertura > > config. I only want one unit tests to run ONE time, but when I add the > > cobertura-maven-plugin to the reporting section, it seems to trigger > another > > surefire:test phase. Any help? > > > > Here is my current config: > > > > > > > > > > org.codehaus.mojo > > cobertura-maven-plugin > > 2.2 > > > > > > site > > pre-site > > > > clean > > > > > > > > instrument > > site > > > > instrument > > cobertura > > > > > > > > > > > > > > org.apache.maven.plugins > > maven-surefire-plugin > > 2.3.1 > > > > once > > > > > > > > net.sourceforge.cobertura.datafile > > > > > > target/cobertura/cobertura.ser > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > org.apache.maven.plugins > > > > maven-project-info-reports-plugin > > > > 2.0.1 > > > > > > > > dependencies > > cim > > project-team > > summary > > issue-tracking > > scm > > index > > > > > > > > > > > > org.apache.maven.plugins > > maven-surefire-report-plugin > > 2.4.2 > > > > > > > > report-only > > > > > > > > > > > > org.codehaus.mojo > > cobertura-maven-plugin > > 2.2 > > > > > > ... > > > > > > > > -- > > Brian > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
