Re: Enabling Eclipse 3.4.0 Ganymede in the maven repository
On Fri, Jul 4, 2008 at 4:49 AM, Rakesh Sinha [EMAIL PROTECTED] wrote: Does this mean if it would be the job of eclipse team to publish the .pom files to the repository. Is there any way any other individual contributor can contribute to this ? It means the latter. You can create a bundle and upload it. In the case of Eclipse with its multitude of jar files, however, I'd ask the repository maintainers first, whether and how its possible to put everything into a single bundle. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proper Dependency Management - HowTo?
Okay, one last thing - this conversation has helped me a LOT already, but, to catch it all, I need some more: 1) You say your version ranges wouldn't break a build - but what about transitive dependencies that these new versions might have (in case they are overwriting depd. mgmt for example)? What about new 3rd party dependencys, what if they have new third party dependencies? When I moved our project from maven to maven 2, with the transitive dependencies the jars /wars of the sub projects each got some new jars, that were not included before, and this sometimes made the project fail at runtime - sometimes even in the most obscure and hidden places, hard to find - same thing could happen with new dependency versions, couldn't it? I am therefore not yet totally convinced of transitive dependencies - it hides things, and then when you don't expect it, it might fail in a productive environment, if a test didn't catch it before. 2) When you are talking about composition, I know finally understood you are talking about using poms as a container to combine dependencies. But how soon will you start making such a combine pom? If you got 2 similar jars? 10? 20? What's the best ratio from your expierence? 3) Will those composition poms not clutter your project structure even more? With maven 1 you had one pom to maintain and to understand - now with maven 2 you already got 2. Now when using composition poms, you will end up with 3,4,510 Poms just got one single project... ??! Our developers are already grumping about having to maintain the parent pom AND their project pom - I mean it has all its nice vantages, but on the other hand, it increases the projects complexity, in some way, too, you have to admit, don't you?! 4) I don't yet completly get the vantage of having all those seperate jars in a single project, instead of one hugh block of code - I mean, yes, when someone breaks something in his own code region, the others may still work on their code without it influencing them - but what about runtime errors - when you are using separate jars its all nice and divided, but this somehow may only delay the error from happening in another remote code region. I mean, imagine everyone is happily working with dependency 1.2.3, now someone releases 1.2.4. To find an obscure bug, it often needs a certain time for ppl to find it, and when everyone is still working with 1.2.3, noone will actually find this error until finally they will change to 1.2.4. I mean, when no separate jars are used, this might sometimes cause the entire project to break - but doesn't that also drastically show everyone that this class / this external jar has influences on all sorts of other code regions? Compare it with teams that are closely working together - the more closer, the more often they might quarrel over something - but as soon as this dispute is resolved, afterwards they will have grown an even better community - where's with closed doors, when they don't see or talk to each other, they won't have problems in the short run, but when they finally meet and talk about things it might bang much stronger Do you get my point? It's hard to explain, I hope you get my analogy. A colleague pointed this out to me, and I didn't know how to answer it - imho it is a valid argument, isn't it??? Last but not least - we have about 10 sub projects, but in one of those sub projects, there are between 1-4 people working. So you still got the problem if you break something in a sub project, you will influence up to 3 other developers Please, bring some light in my confusion! :-) Thanks, Peter
Any maven plugin can load dependencies from eclipse user libraries?
Are there any maven plugins that can load dependencies from user libraries of eclipse? thanx. -- View this message in context: http://www.nabble.com/Any-maven-plugin-can-load-dependencies-from-eclipse-user-libraries--tp18273625p18273625.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: Proper Dependency Management - HowTo?
Hi Peter, Peter Horlock wrote: Okay, one last thing - this conversation has helped me a LOT already, but, to catch it all, I need some more: 1) You say your version ranges wouldn't break a build - but what about transitive dependencies that these new versions might have (in case they are overwriting depd. mgmt for example)? What about new 3rd party dependencys, what if they have new third party dependencies? When I moved our project from maven to maven 2, with the transitive dependencies the jars /wars of the sub projects each got some new jars, that were not included before, and this sometimes made the project fail at runtime - sometimes even in the most obscure and hidden places, hard to find - same thing could happen with new dependency versions, couldn't it? I am therefore not yet totally convinced of transitive dependencies - it hides things, and then when you don't expect it, it might fail in a productive environment, if a test didn't catch it before. That's Michael's point 8. If you upgrade a 3rd party dep, you should really have a look at the dependency tree to see, what has changed. 2) When you are talking about composition, I know finally understood you are talking about using poms as a container to combine dependencies. But how soon will you start making such a combine pom? If you got 2 similar jars? 10? 20? What's the best ratio from your expierence? It depends on your use case how you use a dependency normally. Michael's example was Hibernate. It's more or less always if you recognize that you have to add the same dependencies (and exclusions) in several places only because you like to use framework X in a special way. Checkout also the scope import introduced with M209. 3) Will those composition poms not clutter your project structure even more? With maven 1 you had one pom to maintain and to understand - now with maven 2 you already got 2. Now when using composition poms, you will end up with 3,4,510 Poms just got one single project... ??! Our developers are already grumping about having to maintain the parent pom AND their project pom - I mean it has all its nice vantages, but on the other hand, it increases the projects complexity, in some way, too, you have to admit, don't you?! Managing dependencies *is* complex. Managing them in M1 was worse. Synchronizing a dozen of your projects to use the dependencies in the same versions was horrible (even with entities). The composition poms allow you to have specialists for a framework, who define what is really needed, while all the others simply use the composition pom and can expect that it works. 4) I don't yet completly get the vantage of having all those seperate jars in a single project, instead of one hugh block of code - I mean, yes, when someone breaks something in his own code region, the others may still work on their code without it influencing them - but what about runtime errors - when you are using separate jars its all nice and divided, but this somehow may only delay the error from happening in another remote code region. I mean, imagine everyone is happily working with dependency 1.2.3, now someone releases 1.2.4. To find an obscure bug, it often needs a certain time for ppl to find it, and when everyone is still working with 1.2.3, noone will actually find this error until finally they will change to 1.2.4. I mean, when no separate jars are used, this might sometimes cause the entire project to break - but doesn't that also drastically show everyone that this class / this external jar has influences on all sorts of other code regions? Compare it with teams that are closely working together - the more closer, the more often they might quarrel over something - but as soon as this dispute is resolved, afterwards they will have grown an even better community - where's with closed doors, when they don't see or talk to each other, they won't have problems in the short run, but when they finally meet and talk about things it might bang much stronger Do you get my point? It's hard to explain, I hope you get my analogy. A colleague pointed this out to me, and I didn't know how to answer it - imho it is a valid argument, isn't it??? That's what Michael solves declaring the ranges and we by using SNAPSHOTs. However, it is no automatism for detecting runtime incompatibilities. So write your unit and integration tests ;-) Last but not least - we have about 10 sub projects, but in one of those sub projects, there are between 1-4 people working. So you still got the problem if you break something in a sub project, you will influence up to 3 other developers It's policy. While sub project 3 is working with the latest stuff of sub project 1, sub project 5 might decide not to switch and wait for a stable release and do their integration then. Maven simply helps you to support both scenarios. Please, bring
Re: Proper Dependency Management - HowTo?
Michael McCallum [EMAIL PROTECTED] wrote on 03/07/2008 14:05:09: 11) don't mix inheritance and aggregation. that means a parent pom NEVER ever has modules, if you think about the concept for a minute - or longer - there will be a moment of enlightenment Sorry for jumping in here, but wehy not? The only time (admitedely) I use this is for a multi module J2EE project, where each module (WAR, EAR, EJB, JAR etc) all have the multi module pom as their parent, and the multi module pom has the corporate one as it's parent. I was told to do this, and in fact, if you you use archetype:create-from-project (?) that is how it generates the pom structure of the generated archetype. So, I'm curious as to why you would say not to do this. -Chris ** CAUTION - This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must: - Not use, copy, distribute or disclose it to anyone other than the addressee; - Notify the sender via return email; and - Delete the message (and any related attachments) from your computer immediately. Internet emails are not necessarily secure. Australian Associated Motors Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do not accept responsibility for changes made to this message after it was sent. Unless otherwise stated, views expressed within this email are the author's own and do not represent those of AAMI. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
depend on a multi-module project
Hi, I am trying to refer to a multi-module project in my own project. For example, selenium-rc is a top level pom project containing a number of modules and I'd like to use all such modules. So, in my pom.xml I have: dependency groupIdorg.openqa.selenium/groupId artifactIdselenium-rc/artifactId version0.9.2/version scopetest/scope /dependency It doesn't work. It is trying to download a jar file for the top level project which of course doesn't exist. Any idea? Thanks in advance! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Any maven plugin can load dependencies from eclipse user libraries?
Hi Vickey! I'm not aware, but it seems very unlikely. A maven build should always be possible regardless if the developer use idea, eclipse, netbeans, vi or whatever. So the support for those IDEs is only a one-way from maven to this IDE, but I don't know one single point where the data flows in the other direction. Also, a dependency in maven should alway be deterministic. What if you install your compiled jar/war/ear/whatever in a public repo. Where do all the other people get your eclipse user-lib dependency from? ;) LieGrü, strub --- Vickey [EMAIL PROTECTED] schrieb am Fr, 4.7.2008: Von: Vickey [EMAIL PROTECTED] Betreff: Any maven plugin can load dependencies from eclipse user libraries? An: users@maven.apache.org Datum: Freitag, 4. Juli 2008, 8:29 Are there any maven plugins that can load dependencies from user libraries of eclipse? thanx. __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to package test souce code?
I run mvn package only package the java code into a jar file. How can I package the test code? -- View this message in context: http://www.nabble.com/How-to-package-test-souce-code--tp18274870p18274870.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: How to package test souce code?
Hi, You can use the maven-jar-plugin [1] with the test-jar goal. Or you can use the maven-assembly-plugin [2] . If what you want to do is only to package the tests classes in a jar file, run mvn jar:test-jar. If you want it to be done automatically in your build, configure the plugin in your pom. [1] http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html [2] http://maven.apache.org/plugins/maven-assembly-plugin/ Regards.
Re: AW: Any maven plugin can load dependencies from eclipse user libraries?
struberg wrote: Hi Vickey! I'm not aware, but it seems very unlikely. A maven build should always be possible regardless if the developer use idea, eclipse, netbeans, vi or whatever. So the support for those IDEs is only a one-way from maven to this IDE, but I don't know one single point where the data flows in the other direction. Also, a dependency in maven should alway be deterministic. What if you install your compiled jar/war/ear/whatever in a public repo. Where do all the other people get your eclipse user-lib dependency from? ;) LieGrü, strub --- Vickey [EMAIL PROTECTED] schrieb am Fr, 4.7.2008: Von: Vickey [EMAIL PROTECTED] Betreff: Any maven plugin can load dependencies from eclipse user libraries? An: users@maven.apache.org Datum: Freitag, 4. Juli 2008, 8:29 Are there any maven plugins that can load dependencies from user libraries of eclipse? thanx. __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I know it seems a quite weird demand, maven plugins should not depend on any ide, but the senario is, firstly, some developers in my team who have never used maven before have defined the dependencies with eclipse user libraries, secondery, javadoc and source location of dependencies seems not be able to be defined in pom.xml files, loading dependencies in such way just for the sake of the convenience eclipseonce javadoc and source code location are defined in user libraries, developers can open the api reference of the corresponding code with just a single press of F1 in eclipse. -- View this message in context: http://www.nabble.com/Any-maven-plugin-can-load-dependencies-from-eclipse-user-libraries--tp18273625p18275575.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: Proper Dependency Management - HowTo?
11) don't mix inheritance and aggregation. that means a parent pom NEVER ever has modules, if you think about the concept for a minute - or longer - there will be a moment of enlightenment structure of the generated archetype. So, I'm curious as to why you would say not to do this. Yeah, me too! First, I had a parent pom, and a all-projects-pom which was just and only a multimodule pom. But then you had even one more pom, and we decided to put the multimodule stuff right into the parent pom. using the -N flag allows to simply work (package, install, deploy, site...) with the parent pom, while without you may easily work(package, install, deploy, site...) on all projects at once. Thanks, Peter
Re: AW: Any maven plugin can load dependencies from eclipse user libraries?
If you take the user libraries and write all the dependencies to the pom, your colleagues will not notice much a difference after a mvn eclipse:eclipse The Javadoc is usually already in the maven repo. So if you take an artifact from a public repo you will almost always find an attached sources.jar artifact. The same applies if you release your own modules into a private company repository. So even debugging is not a problem. LieGrü, strub --- Vickey [EMAIL PROTECTED] schrieb am Fr, 4.7.2008: I know it seems a quite weird demand, maven plugins should not depend on any ide, but the senario is, firstly, some developers in my team who have never used maven before have defined the dependencies with eclipse user libraries, secondery, javadoc and source location of dependencies seems not be able to be defined in pom.xml files, loading dependencies in such way just for the sake of the convenience eclipseonce javadoc and source code location are defined in user libraries, developers can open the api reference of the corresponding code with just a single press of F1 in eclipse. __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Any maven plugin can load dependencies from eclipse user libraries?
Btw, how do you perform nightly builds, continuous integration, automated regression tests, etc if your build only works with eclipse (To be more specific: with a dedicated eclipse installation/configuration)? You will get all those out of the box for free if you use maven the 'maven-way' :) hth, mark --- Mark Struberg [EMAIL PROTECTED] schrieb am Fr, 4.7.2008: Von: Mark Struberg [EMAIL PROTECTED] Betreff: Re: AW: Any maven plugin can load dependencies from eclipse user libraries? An: Maven Users List users@maven.apache.org Datum: Freitag, 4. Juli 2008, 13:51 If you take the user libraries and write all the dependencies to the pom, your colleagues will not notice much a difference after a mvn eclipse:eclipse The Javadoc is usually already in the maven repo. So if you take an artifact from a public repo you will almost always find an attached sources.jar artifact. The same applies if you release your own modules into a private company repository. So even debugging is not a problem. LieGrü, strub --- Vickey [EMAIL PROTECTED] schrieb am Fr, 4.7.2008: I know it seems a quite weird demand, maven plugins should not depend on any ide, but the senario is, firstly, some developers in my team who have never used maven before have defined the dependencies with eclipse user libraries, secondery, javadoc and source location of dependencies seems not be able to be defined in pom.xml files, loading dependencies in such way just for the sake of the convenience eclipseonce javadoc and source code location are defined in user libraries, developers can open the api reference of the corresponding code with just a single press of F1 in eclipse. __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
Yes, I did. It got downloaded, along with the newer doxia. I assume
it's getting used.
I think it's good practice to specify the version on your build and
reporting plugins to ensure repeatability of builds.
-K
On Jul 3, 2008, at 3:30 PM, Dennis Lundberg wrote:
Kathryn Huxtable wrote:
I don't see that MSITE-274 (spaces added) is fixed. I'm still
getting the extra spaces. -K
I don't get the extra spaces when I specify version 2.0-beta-7. Did
you explicitly say this in your POM?
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
...
/plugins
/build
...
/project
On Jul 3, 2008, at 12:34 AM, Dennis Lundberg wrote:
The Maven team is pleased to announce the release of the Maven Site
Plugin, version 2.0-beta-7
The Maven 2 Site plugin is used to generate a site for the
project. The
generated site also includes the project's report distributions
that was
configured in the reporting section of the pom.
http://maven.apache.org/plugins/maven-site-plugin/
You can run mvn -up to get the latest version of the plugin, or
specify
the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
Release Notes - Maven 2.x Site Plugin - Version 2.0-beta-7
** Bug
* [MSITE-25] - mvn site:deploy and site:stage-deploy ignores
server
configuration in settings.xml
* [MSITE-143] - SCP works for deploy goal, but not for site-deploy
* [MSITE-174] - Default bundle used not correct
* [MSITE-211] - Can't deploy site using site:deploy due to a
ProxyHTTP error
* [MSITE-262] - site.xml not inherited if build run from parent
* [MSITE-270] - site.xml: menus inherited that should not
* [MSITE-271] - Page title reads Introduction to $project.name
* [MSITE-274] - space/newline added after added after anchor,
link,
bold, italic and monospaced tags
* [MSITE-304] - site:stage-deploy creates different directory
structure than site:site
* [MSITE-313] - Use proper file encoding when storing site
descriptor in local repo
* [MSITE-316] - Broken links to submodules when staging site
* [MSITE-317] - User proper encoding when interpolating site
descriptor
* [MSITE-341] - 'nonProxyHosts' element is not handled when we
deploy a site
** Improvement
* [MSITE-199] - Add publishDate position none
* [MSITE-280] - Fix FAQ entry about staging
* [MSITE-281] - Employ consistent typesetting/formatting
* [MSITE-290] - Move logic from AbstractSiteMojo and
AbstractSiteRenderingMojo for Doxia related stuff
* [MSITE-292] - Swedish translation for the site
* [MSITE-303] - Discard invalid characters from directory name
generated for staging site
* [MSITE-314] - use ${project.build.sourceEncoding} as default
value for inputEncoding parameter
** New Feature
* [MSITE-212] - Catalan Language
* [MSITE-251] - tr locale support
* [MSITE-328] - Danish internationalization properties file
** Task
* [MSITE-327] - Use Doxia 1.0-alpha-11
* [MSITE-335] - Use maven-doxia-tools 1.0.1
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
-
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: [ANN] Maven Site Plugin 2.0-beta-7 Released
So I intended also to ask if I should maybe be looking at anything
else. Consider it asked. -K
On Jul 4, 2008, at 9:53 AM, Kathryn Huxtable wrote:
Yes, I did. It got downloaded, along with the newer doxia. I assume
it's getting used.
I think it's good practice to specify the version on your build and
reporting plugins to ensure repeatability of builds.
-K
On Jul 3, 2008, at 3:30 PM, Dennis Lundberg wrote:
Kathryn Huxtable wrote:
I don't see that MSITE-274 (spaces added) is fixed. I'm still
getting the extra spaces. -K
I don't get the extra spaces when I specify version 2.0-beta-7. Did
you explicitly say this in your POM?
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
...
/plugins
/build
...
/project
On Jul 3, 2008, at 12:34 AM, Dennis Lundberg wrote:
The Maven team is pleased to announce the release of the Maven Site
Plugin, version 2.0-beta-7
The Maven 2 Site plugin is used to generate a site for the
project. The
generated site also includes the project's report distributions
that was
configured in the reporting section of the pom.
http://maven.apache.org/plugins/maven-site-plugin/
You can run mvn -up to get the latest version of the plugin, or
specify
the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
Release Notes - Maven 2.x Site Plugin - Version 2.0-beta-7
** Bug
* [MSITE-25] - mvn site:deploy and site:stage-deploy ignores
server
configuration in settings.xml
* [MSITE-143] - SCP works for deploy goal, but not for site-deploy
* [MSITE-174] - Default bundle used not correct
* [MSITE-211] - Can't deploy site using site:deploy due to a
ProxyHTTP error
* [MSITE-262] - site.xml not inherited if build run from parent
* [MSITE-270] - site.xml: menus inherited that should not
* [MSITE-271] - Page title reads Introduction to $project.name
* [MSITE-274] - space/newline added after added after anchor,
link,
bold, italic and monospaced tags
* [MSITE-304] - site:stage-deploy creates different directory
structure than site:site
* [MSITE-313] - Use proper file encoding when storing site
descriptor in local repo
* [MSITE-316] - Broken links to submodules when staging site
* [MSITE-317] - User proper encoding when interpolating site
descriptor
* [MSITE-341] - 'nonProxyHosts' element is not handled when we
deploy a site
** Improvement
* [MSITE-199] - Add publishDate position none
* [MSITE-280] - Fix FAQ entry about staging
* [MSITE-281] - Employ consistent typesetting/formatting
* [MSITE-290] - Move logic from AbstractSiteMojo and
AbstractSiteRenderingMojo for Doxia related stuff
* [MSITE-292] - Swedish translation for the site
* [MSITE-303] - Discard invalid characters from directory name
generated for staging site
* [MSITE-314] - use ${project.build.sourceEncoding} as default
value for inputEncoding parameter
** New Feature
* [MSITE-212] - Catalan Language
* [MSITE-251] - tr locale support
* [MSITE-328] - Danish internationalization properties file
** Task
* [MSITE-327] - Use Doxia 1.0-alpha-11
* [MSITE-335] - Use maven-doxia-tools 1.0.1
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
-
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: [ANN] Maven Site Plugin 2.0-beta-7 Released
I can say, having looked at the HTML produced, that all the anchor
tags have newlines following them. This is generating the extra space.
For instance, the APT text
After reading this document, if you desire more detailed design
information, go to
{{{design.html}Design}}.
Depending on your interest, you may also wish to go to
{{{deployment-guide.html}Deployment Guide}} or {{{user-
manual.html}User Manual}}.
Turns into
After reading this document, if you desire more detailed design
information, go to a href=design.htmlDesign/a
. Depending on your interest, you may also wish to go to a
href=deployment-guide.htmlDeployment Guide/a
or a href=user-manual.htmlUser Manual/a
.
Hopefully the line breaks will come through in the email.
-K
On Jul 4, 2008, at 9:56 AM, Kathryn Huxtable wrote:
So I intended also to ask if I should maybe be looking at anything
else. Consider it asked. -K
On Jul 4, 2008, at 9:53 AM, Kathryn Huxtable wrote:
Yes, I did. It got downloaded, along with the newer doxia. I assume
it's getting used.
I think it's good practice to specify the version on your build and
reporting plugins to ensure repeatability of builds.
-K
On Jul 3, 2008, at 3:30 PM, Dennis Lundberg wrote:
Kathryn Huxtable wrote:
I don't see that MSITE-274 (spaces added) is fixed. I'm still
getting the extra spaces. -K
I don't get the extra spaces when I specify version 2.0-beta-7.
Did you explicitly say this in your POM?
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
...
/plugins
/build
...
/project
On Jul 3, 2008, at 12:34 AM, Dennis Lundberg wrote:
The Maven team is pleased to announce the release of the Maven
Site
Plugin, version 2.0-beta-7
The Maven 2 Site plugin is used to generate a site for the
project. The
generated site also includes the project's report distributions
that was
configured in the reporting section of the pom.
http://maven.apache.org/plugins/maven-site-plugin/
You can run mvn -up to get the latest version of the plugin, or
specify
the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
Release Notes - Maven 2.x Site Plugin - Version 2.0-beta-7
** Bug
* [MSITE-25] - mvn site:deploy and site:stage-deploy ignores
server
configuration in settings.xml
* [MSITE-143] - SCP works for deploy goal, but not for site-deploy
* [MSITE-174] - Default bundle used not correct
* [MSITE-211] - Can't deploy site using site:deploy due to a
ProxyHTTP error
* [MSITE-262] - site.xml not inherited if build run from parent
* [MSITE-270] - site.xml: menus inherited that should not
* [MSITE-271] - Page title reads Introduction to $project.name
* [MSITE-274] - space/newline added after added after anchor,
link,
bold, italic and monospaced tags
* [MSITE-304] - site:stage-deploy creates different directory
structure than site:site
* [MSITE-313] - Use proper file encoding when storing site
descriptor in local repo
* [MSITE-316] - Broken links to submodules when staging site
* [MSITE-317] - User proper encoding when interpolating site
descriptor
* [MSITE-341] - 'nonProxyHosts' element is not handled when we
deploy a site
** Improvement
* [MSITE-199] - Add publishDate position none
* [MSITE-280] - Fix FAQ entry about staging
* [MSITE-281] - Employ consistent typesetting/formatting
* [MSITE-290] - Move logic from AbstractSiteMojo and
AbstractSiteRenderingMojo for Doxia related stuff
* [MSITE-292] - Swedish translation for the site
* [MSITE-303] - Discard invalid characters from directory name
generated for staging site
* [MSITE-314] - use ${project.build.sourceEncoding} as default
value for inputEncoding parameter
** New Feature
* [MSITE-212] - Catalan Language
* [MSITE-251] - tr locale support
* [MSITE-328] - Danish internationalization properties file
** Task
* [MSITE-327] - Use Doxia 1.0-alpha-11
* [MSITE-335] - Use maven-doxia-tools 1.0.1
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
If you want to try it out, the code is available at
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/i2mi login
$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/home/cvs/i2mi co
ldappc-mvn
The tests are broken at the moment, but not relevant for the site, so
adding -Dmaven.test.skip=true will be necessary.
-K
On Jul 4, 2008, at 10:44 AM, Kathryn Huxtable wrote:
I can say, having looked at the HTML produced, that all the anchor
tags have newlines following them. This is generating the extra space.
For instance, the APT text
After reading this document, if you desire more detailed design
information, go to
{{{design.html}Design}}.
Depending on your interest, you may also wish to go to
{{{deployment-guide.html}Deployment Guide}} or {{{user-
manual.html}User Manual}}.
Turns into
After reading this document, if you desire more detailed design
information, go to a href=design.htmlDesign/a
. Depending on your interest, you may also wish to go to a
href=deployment-guide.htmlDeployment Guide/a
or a href=user-manual.htmlUser Manual/a
.
Hopefully the line breaks will come through in the email.
-K
On Jul 4, 2008, at 9:56 AM, Kathryn Huxtable wrote:
So I intended also to ask if I should maybe be looking at anything
else. Consider it asked. -K
On Jul 4, 2008, at 9:53 AM, Kathryn Huxtable wrote:
Yes, I did. It got downloaded, along with the newer doxia. I
assume it's getting used.
I think it's good practice to specify the version on your build
and reporting plugins to ensure repeatability of builds.
-K
On Jul 3, 2008, at 3:30 PM, Dennis Lundberg wrote:
Kathryn Huxtable wrote:
I don't see that MSITE-274 (spaces added) is fixed. I'm still
getting the extra spaces. -K
I don't get the extra spaces when I specify version 2.0-beta-7.
Did you explicitly say this in your POM?
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
...
/plugins
/build
...
/project
On Jul 3, 2008, at 12:34 AM, Dennis Lundberg wrote:
The Maven team is pleased to announce the release of the Maven
Site
Plugin, version 2.0-beta-7
The Maven 2 Site plugin is used to generate a site for the
project. The
generated site also includes the project's report distributions
that was
configured in the reporting section of the pom.
http://maven.apache.org/plugins/maven-site-plugin/
You can run mvn -up to get the latest version of the plugin, or
specify
the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
Release Notes - Maven 2.x Site Plugin - Version 2.0-beta-7
** Bug
* [MSITE-25] - mvn site:deploy and site:stage-deploy ignores
server
configuration in settings.xml
* [MSITE-143] - SCP works for deploy goal, but not for site-
deploy
* [MSITE-174] - Default bundle used not correct
* [MSITE-211] - Can't deploy site using site:deploy due to a
ProxyHTTP error
* [MSITE-262] - site.xml not inherited if build run from parent
* [MSITE-270] - site.xml: menus inherited that should not
* [MSITE-271] - Page title reads Introduction to $project.name
* [MSITE-274] - space/newline added after added after anchor,
link,
bold, italic and monospaced tags
* [MSITE-304] - site:stage-deploy creates different directory
structure than site:site
* [MSITE-313] - Use proper file encoding when storing site
descriptor in local repo
* [MSITE-316] - Broken links to submodules when staging site
* [MSITE-317] - User proper encoding when interpolating site
descriptor
* [MSITE-341] - 'nonProxyHosts' element is not handled when we
deploy a site
** Improvement
* [MSITE-199] - Add publishDate position none
* [MSITE-280] - Fix FAQ entry about staging
* [MSITE-281] - Employ consistent typesetting/formatting
* [MSITE-290] - Move logic from AbstractSiteMojo and
AbstractSiteRenderingMojo for Doxia related stuff
* [MSITE-292] - Swedish translation for the site
* [MSITE-303] - Discard invalid characters from directory name
generated for staging site
* [MSITE-314] - use ${project.build.sourceEncoding} as default
value for inputEncoding parameter
** New Feature
* [MSITE-212] - Catalan Language
* [MSITE-251] - tr locale support
* [MSITE-328] - Danish internationalization properties file
** Task
* [MSITE-327] - Use Doxia 1.0-alpha-11
* [MSITE-335] - Use maven-doxia-tools 1.0.1
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
-
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
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
Okay, I deleted the older site plugins from my local repo and rebuild
the site. It downloaded version 2.0-beta-6, despite my having, so far
as I know, no references to it, and a specific reference to 2.0-beta-7
in my pom.xml file.
I'm bewildered. Surely there are no transitive reporting dependencies
in single module projects...
-K
On Jul 4, 2008, at 10:49 AM, Kathryn Huxtable wrote:
If you want to try it out, the code is available at
$ cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs/i2mi login
$ cvs -z3 -d :pserver:[EMAIL PROTECTED]:/home/cvs/i2mi
co ldappc-mvn
The tests are broken at the moment, but not relevant for the site,
so adding -Dmaven.test.skip=true will be necessary.
-K
On Jul 4, 2008, at 10:44 AM, Kathryn Huxtable wrote:
I can say, having looked at the HTML produced, that all the anchor
tags have newlines following them. This is generating the extra
space.
For instance, the APT text
After reading this document, if you desire more detailed design
information, go to
{{{design.html}Design}}.
Depending on your interest, you may also wish to go to
{{{deployment-guide.html}Deployment Guide}} or {{{user-
manual.html}User Manual}}.
Turns into
After reading this document, if you desire more detailed design
information, go to a href=design.htmlDesign/a
. Depending on your interest, you may also wish to go to a
href=deployment-guide.htmlDeployment Guide/a
or a href=user-manual.htmlUser Manual/a
.
Hopefully the line breaks will come through in the email.
-K
On Jul 4, 2008, at 9:56 AM, Kathryn Huxtable wrote:
So I intended also to ask if I should maybe be looking at anything
else. Consider it asked. -K
On Jul 4, 2008, at 9:53 AM, Kathryn Huxtable wrote:
Yes, I did. It got downloaded, along with the newer doxia. I
assume it's getting used.
I think it's good practice to specify the version on your build
and reporting plugins to ensure repeatability of builds.
-K
On Jul 3, 2008, at 3:30 PM, Dennis Lundberg wrote:
Kathryn Huxtable wrote:
I don't see that MSITE-274 (spaces added) is fixed. I'm still
getting the extra spaces. -K
I don't get the extra spaces when I specify version 2.0-beta-7.
Did you explicitly say this in your POM?
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
...
/plugins
/build
...
/project
On Jul 3, 2008, at 12:34 AM, Dennis Lundberg wrote:
The Maven team is pleased to announce the release of the Maven
Site
Plugin, version 2.0-beta-7
The Maven 2 Site plugin is used to generate a site for the
project. The
generated site also includes the project's report
distributions that was
configured in the reporting section of the pom.
http://maven.apache.org/plugins/maven-site-plugin/
You can run mvn -up to get the latest version of the plugin,
or specify
the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.0-beta-7/version
/plugin
Release Notes - Maven 2.x Site Plugin - Version 2.0-beta-7
** Bug
* [MSITE-25] - mvn site:deploy and site:stage-deploy ignores
server
configuration in settings.xml
* [MSITE-143] - SCP works for deploy goal, but not for site-
deploy
* [MSITE-174] - Default bundle used not correct
* [MSITE-211] - Can't deploy site using site:deploy due to a
ProxyHTTP error
* [MSITE-262] - site.xml not inherited if build run from parent
* [MSITE-270] - site.xml: menus inherited that should not
* [MSITE-271] - Page title reads Introduction to $project.name
* [MSITE-274] - space/newline added after added after anchor,
link,
bold, italic and monospaced tags
* [MSITE-304] - site:stage-deploy creates different directory
structure than site:site
* [MSITE-313] - Use proper file encoding when storing site
descriptor in local repo
* [MSITE-316] - Broken links to submodules when staging site
* [MSITE-317] - User proper encoding when interpolating site
descriptor
* [MSITE-341] - 'nonProxyHosts' element is not handled when we
deploy a site
** Improvement
* [MSITE-199] - Add publishDate position none
* [MSITE-280] - Fix FAQ entry about staging
* [MSITE-281] - Employ consistent typesetting/formatting
* [MSITE-290] - Move logic from AbstractSiteMojo and
AbstractSiteRenderingMojo for Doxia related stuff
* [MSITE-292] - Swedish translation for the site
* [MSITE-303] - Discard invalid characters from directory name
generated for staging site
* [MSITE-314] - use ${project.build.sourceEncoding} as default
value for inputEncoding parameter
** New Feature
* [MSITE-212] - Catalan Language
* [MSITE-251] - tr locale support
* [MSITE-328] - Danish internationalization properties file
** Task
* [MSITE-327] - Use Doxia 1.0-alpha-11
* [MSITE-335] - Use maven-doxia-tools 1.0.1
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
Okay, I renamed my entire repository and started from scratch. After several attempts with strange results, I removed the maven-site-plugin directory from my local repository and ran the command at the head of the attached file. I'm also attaching my pom. Note that it downloads both the beta-6 and beta-7 versions of site, then throws an exception in the site plugin. If I do exactly the same run again, no exceptions are thrown, it completes successfully, but seems to be running the beta-6 release. -K bash-3.2$ mvn -Dmaven.test.skip=true -e clean site + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building LDAP Provisioning Connector [INFO]task-segment: [clean, site] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/huxtable/dev/workspace/ldappc/target Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom 10K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.jar 118K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.pom 11K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.jar 121K downloaded [INFO] Reloading plugin container for: org.apache.maven.plugins:maven-site-plugin. The plugin artifact has changed. [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] ** ... Eliding lots of Velocity and other info messages ... [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:562) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin' at
Re: Proper Dependency Management - HowTo?
Michael McCallum wrote: On Fri, 04 Jul 2008 03:59:29 Peter Horlock wrote: Sorry, but what's the purpose of the release plugin anyway? It's site doesn't really tell it: http://maven.apache.org/plugins/maven-release-plugin/ Very good question and simple to answer... release-prepare - the release plugin will build and test your project then tag it. One important point not mentioned: It *ensures* that you have *no* local changes. :) release-perform -check out the code from the tag and build the artifact and test it and then deploy it essentially a maven repository is just a cache of prebuilt tags, you can always rebuild an artifact by providing the tag path to release-perform once you are in the habit of releasing and set up some aliases or batch files its painless, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
You define the site plugin inside reporting, I guess you want it inside build. I can confirm that MSITE-274 is fixed for me with beta-7. HTH, -Lukas Kathryn Huxtable wrote: Okay, I renamed my entire repository and started from scratch. After several attempts with strange results, I removed the maven-site-plugin directory from my local repository and ran the command at the head of the attached file. I'm also attaching my pom. Note that it downloads both the beta-6 and beta-7 versions of site, then throws an exception in the site plugin. If I do exactly the same run again, no exceptions are thrown, it completes successfully, but seems to be running the beta-6 release. -K bash-3.2$ mvn -Dmaven.test.skip=true -e clean site + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building LDAP Provisioning Connector [INFO]task-segment: [clean, site] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/huxtable/dev/workspace/ldappc/target Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom 10K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.jar 118K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.pom 11K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.jar 121K downloaded [INFO] Reloading plugin container for: org.apache.maven.plugins:maven-site-plugin. The plugin artifact has changed. [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] ** ... Eliding lots of Velocity and other info messages ... [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:562) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by:
Re: Proper Dependency Management - HowTo?
Michael McCallum wrote: On Fri, 04 Jul 2008 02:43:03 Jörg Schaible wrote: Sorry, but our priority is to ensure that all artifacts are built with the same plugins and use the same artifact versions. In your model I have to duplicate all the versions for your individual service parents. That's what I call an anti-pattern. No, thanks, we've already bitten enough by that. I do specific plugin versions strictly and dependency versions strictly too. Its just the one is by composition and one by inheritance. Consider this thought experiment: 1) push all your configuration down to the leaf poms 2) there will be tonnes of duplication 3) now look at the patterns of duplication 4) you can use standard factoring techniques to take common sets of dependencies and put them into a composition (a pom which just collects other dependencies) (its even possible to put dependency management in here. 5) once you have factored out all the common dependencies you will see the the remaining patterns of configuration fall into functional groups... one for jars, one for wars, one for ears, one for jaxb2 projects etc etc (one could be n). So step 5 says to pull up that configuration into common parents by fucntion not by group. I guarantee that if you do this your poms will halve in size One of the _really_ important features of using composition whether or not you use depMgt is that you can (with version ranges) make a change that remains consistent across all your projects To prove this consider A extends P-1 and B extends P-2. P-2 changes the version of commons collections however C depends on A and B which version do I end up with in C? It either depends on the order of resolution of A and B OR i can add commons collections to C as well. It becomes really unwieldy. You need to factor and isolate, I'm sure it makes perfect sense. Maybe I'm missing something but I've been doing this for several years and it works. Yep. You miss that with a global POM that defines commons-collection I do not have to declare commons-collection in C, since the depMgnt of the global parent will take precedence over any (transitive) version used originally in A or B (since M206). Note, that we use only the global POM (or project POM) to define versions in the depMgnt, deps in the modules do never ever have any own version declared (mufti order). However, the global inherited POM is necessary to lock down the versions of the plugins. This cannot be done with composition. And the usage of the same versions for plugins is essential, M2 will load every plugin only once within the same multi-project build (resulting in the unfortunate fact that you have to declare any additional dep of the antrun-plugin once alltogether). All kind of individual plugin configuration tend to be really individual. As long as Maven does not support to reuse certain POM sections (like it is now available with scope import at least for the depMgmnt), you will not be able to avoid some duplication in the POMs. the plugin configurations are merged so you can override specific properties in the child with the 'abstract' configuration resolve from the parent hierachy The overhead of putting things in the company pom is that you need to change all the projects to the new version OR you can use snapshots and make it a major overhead to start a release cycle It depends on your development model. We do the second and it works well. it does and thats fair enough. But I worked on another project where they did the same thing and said it worked well. But people still wasted half days all the time when someone snapshot'd something that broke everything else accidentally and there was no simple path backward. You might as well go back to one big source tree... OK. There's one point why it might work for us better: we do not *deploy* SNAPSHOTs i.e. everyone has to build those locally. Please take all comments with a large grain of salt. Not intending to offend anyone, ;-) Fine with me. All I wanted was to show Peter that different strategies exist that may work out for him. One question remains: How do you lock down the dependency versions for the end product? A.jar is currently 1.1.1 B.ejb is currently 2.2.1 and depends on A[1,2-!) C.ear is currently 3.1.0 and depends on B[2,3-!) Now you deliver C.ear. You do a fix for A.jar resulting in 1.1.2. For some QA reason you will have to rebuild C-3.1.0.ear from the subversion tag == C-3.1.0.ear is now different - and worse, it is broken, since it contains suddenly a newer A-1.1.2.jar, while B-2.2.1.ejb still refers in the classpath of its Manifest A-1.1.1.jar. How do you address this QA problem? - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running MVN Plugin from POM.xml VS Command-Line
I have tried running a Maven plugin from a directory which has my standard java maven structure and pom.xml. From this directory, I run the following command: mvn test-group:test-plugin:TEST:work Here, I got wrong results. However, when I bound this plugin to a phase in the pom.xml (e.g. deploy) and ran the following: mvn deploy Then the plugin executed correctly. Why doesnt the plugin work from the command line when invoked directly but only works in the POM.xml when bound to a phase? Please let me know what Im doing wrong. Thanks. 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: Running MVN Plugin from POM.xml VS Command-Line
On Fri, Jul 4, 2008 at 6:35 PM, Morgovsky, Alexander (US - Glen Mills) [EMAIL PROTECTED] wrote: However, when I bound this plugin to a phase in the pom.xml (e.g. deploy) and ran the following: mvn deploy Then the plugin executed correctly. Why doesnt the plugin work from the command line when invoked directly but only works in the POM.xml when bound to a phase? Please let me know what Im doing wrong. Thanks. When you type 'mvn deploy' you are not invoking the deploy plugin, you're telling Maven to go through the build lifecycle and execute all the plugins bound to the various phases up to and including the deploy phase. The default executions will depend on the packaging for that pom, and then whatever additional plugins you have configured will also be executed. My guess is that the plugin goal needs something from one of the earlier phases, so executing it in isolation doesn't work. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Site Plugin 2.0-beta-7 Released
Thanks, that did the trick! -K On Jul 4, 2008, at 3:08 PM, Lukas Theussl wrote: You define the site plugin inside reporting, I guess you want it inside build. I can confirm that MSITE-274 is fixed for me with beta-7. HTH, -Lukas Kathryn Huxtable wrote: Okay, I renamed my entire repository and started from scratch. After several attempts with strange results, I removed the maven- site-plugin directory from my local repository and ran the command at the head of the attached file. I'm also attaching my pom. Note that it downloads both the beta-6 and beta-7 versions of site, then throws an exception in the site plugin. If I do exactly the same run again, no exceptions are thrown, it completes successfully, but seems to be running the beta-6 release. -K bash-3.2$ mvn -Dmaven.test.skip=true -e clean site + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building LDAP Provisioning Connector [INFO]task-segment: [clean, site] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /Users/huxtable/dev/workspace/ldappc/target Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom 10K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.jar 118K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.pom 11K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-7/maven-site-plugin-2.0-beta-7.jar 121K downloaded [INFO] Reloading plugin container for: org.apache.maven.plugins:maven-site-plugin. The plugin artifact has changed. [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] ** ... Eliding lots of Velocity and other info messages ... [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin: 2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site- plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-site- plugin:2.0-beta-6:site. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-6:site': Unable to find the mojo 'org.apache.maven.plugins:maven-site-plugin: 2.0-beta-6:site' in the plugin 'org.apache.maven.plugins:maven-site- plugin' at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoals(DefaultLifecycleExecutor.java:562) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 478) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:291) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java: 315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at
