Re: problem with custom check in checkstyle plugin
On Feb 9, 2008 9:03 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > Barrie Treloar wrote: > > On Feb 6, 2008 8:37 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > >> Funny how things in the universe sometimes occur at the exact same time... > >> > >> Yesterday I completely rewrote the example about using custom checks for > >> the Checkstyle plugin. It is now a complete example with all code > >> necessary. It's not published yet, but you can (sort of) read it > >> directly from svn [1] or you can check out the Checkstyle plugin and run > >> 'mvn site' to build the docs yourself. > >> > >> [1] > >> https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/site/apt/examples/custom-developed-checkstyle.apt > > > > Please update the packagenames.xml to be the same as the one from > > within the checkstyle jar. I got stung with a problem because the > > Header check is not listed on the checkstyle web page but is listed > > within the jar file. > > OK, since I took the example file from their site, I probably need to > update as well. I'll look into it. I've already raised a patch request for that page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released
Yes it is. -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED] Sent: Friday, February 08, 2008 8:37 PM To: users@maven.apache.org Subject: Re: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released Is this the new Archetype NG Plugin that allows creating archetypes from existing projects? Thanks, Matt On Feb 8, 2008, at 8:40 PM, Raphaël Piéroni wrote: > The Maven team is pleased to announce the release of the Maven > Archetype Plugin, version 2.0-alpha-1 > > > You can use it by calling mvn archetype:create > > Release Notes - Maven 2.x Archetype Plugin - Version 2.0-alpha-1 > > ** Bug >* [ARCHETYPE-82] - add-groups doesn't create archetype.xml >* [ARCHETYPE-83] - archetypeng:create crashes with > java.lang.ClassNotFoundException: > org.apache.maven.plugin.resource.loader.ProjectResourceLoader >* [ARCHETYPE-84] - need a way to preserve the java package in > create-from-project >* [ARCHETYPE-87] - create-from-project replaces too many things in > the pom with variables >* [ARCHETYPE-88] - sometimes add-groups fails when there is a pom > present >* [ARCHETYPE-90] - all the contents of an archetype shouldn't be > processed by velocity during creation >* [ARCHETYPE-91] - create is prompting for a package >* [ARCHETYPE-93] - archetypeng:create loop forever when the > selected group contains no archetype >* [ARCHETYPE-94] - Archetype not registered when installed in > local repository >* [ARCHETYPE-97] - section is missing after using > create-from-project >* [ARCHETYPE-98] - parents in modules are not always correctly > updated >* [ARCHETYPE-99] - child module is getting replaced with parent > artifactId and groupId >* [ARCHETYPE-100] - sibling dependencies are not updated >* [ARCHETYPE-103] - acrchetype.properties should be in /target > not root >* [ARCHETYPE-104] - module name changed for unknown reason >* [ARCHETYPE-105] - not able to create from project with > sibling-dependencies test project >* [ARCHETYPE-121] - build don't works on windows and jdk1.4 > > ** Improvement >* [ARCHETYPE-114] - NG code should not depend on Maven 2.1 > > ** New Feature >* [ARCHETYPE-95] - Provide creation of partial archetypes in > create-from-project > > ** Task >* [ARCHETYPE-72] - Generate standard archetypes from real projects > > Enjoy, > > -The Maven team - 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 Archetype Plugin 2.0-alpha-1 for Maven 2 Released
Is this the new Archetype NG Plugin that allows creating archetypes from existing projects? Thanks, Matt On Feb 8, 2008, at 8:40 PM, Raphaël Piéroni wrote: The Maven team is pleased to announce the release of the Maven Archetype Plugin, version 2.0-alpha-1 You can use it by calling mvn archetype:create Release Notes - Maven 2.x Archetype Plugin - Version 2.0-alpha-1 ** Bug * [ARCHETYPE-82] - add-groups doesn't create archetype.xml * [ARCHETYPE-83] - archetypeng:create crashes with java.lang.ClassNotFoundException: org.apache.maven.plugin.resource.loader.ProjectResourceLoader * [ARCHETYPE-84] - need a way to preserve the java package in create-from-project * [ARCHETYPE-87] - create-from-project replaces too many things in the pom with variables * [ARCHETYPE-88] - sometimes add-groups fails when there is a pom present * [ARCHETYPE-90] - all the contents of an archetype shouldn't be processed by velocity during creation * [ARCHETYPE-91] - create is prompting for a package * [ARCHETYPE-93] - archetypeng:create loop forever when the selected group contains no archetype * [ARCHETYPE-94] - Archetype not registered when installed in local repository * [ARCHETYPE-97] - section is missing after using create-from-project * [ARCHETYPE-98] - parents in modules are not always correctly updated * [ARCHETYPE-99] - child module is getting replaced with parent artifactId and groupId * [ARCHETYPE-100] - sibling dependencies are not updated * [ARCHETYPE-103] - acrchetype.properties should be in /target not root * [ARCHETYPE-104] - module name changed for unknown reason * [ARCHETYPE-105] - not able to create from project with sibling-dependencies test project * [ARCHETYPE-121] - build don't works on windows and jdk1.4 ** Improvement * [ARCHETYPE-114] - NG code should not depend on Maven 2.1 ** New Feature * [ARCHETYPE-95] - Provide creation of partial archetypes in create-from-project ** Task * [ARCHETYPE-72] - Generate standard archetypes from real projects Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Day for folks in the Bay Area
Hi, For people interested in some enterprise Maven user stories, some information on development in 2.1. We will also be doing a demonstration of Nexus, a demonstration of M2Eclipse, and a demonstration of our M2Eclipse/Nexus integration. Myself, Brian Fox, and Ralph Goers will be there to answer Maven questions people might have as well. We're very fortunate that Intuit is going to be providing space for our event. The event will be held next Friday (the 15th) starting in the early afternoon. We'll post the exact time early next week. We're still sorting out some of the logistics but just wanted to get the word out. The event will be held at the address below. Intuit building 9, 2600 Casey Ave. Here's the map. http://maps.google.com/maps?f=d&hl=en&geocode=&saddr=&daddr=37.431978,-1 22.096756&mra=mi&mrsp=0&sz=17&sll=37.432554,-122.097609&sspn=0.007932,0. 013475&layer=c&ie=UTF8&t=h&z=17&om=0&cbll=37.431978,-122.096756 Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released --> Ref #[1MFmL2JXIy0Ismu]
Hello, Thank you for contacting NetZero. This is an automated reply and no further response will be sent. Please do not reply to this email. If you are looking for help here are some useful links: * Online NetZero Help Center: http://www.netzero.com/support * Online Billing and Account Center: https://account.netzero.net * Reset/Retrieve your Password: http://my.netzero.com/s/resetpassword * Lookup Access Numbers in your area: http://my.netzero.com/s/numbers * Contact Us: http://www.netzero.net/support/support.html Thank you for choosing NetZero. Sincerely, NetZero Customer Support - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released
Nice work Raphaël. On 8-Feb-08, at 7:40 PM, Raphaël Piéroni wrote: The Maven team is pleased to announce the release of the Maven Archetype Plugin, version 2.0-alpha-1 You can use it by calling mvn archetype:create Release Notes - Maven 2.x Archetype Plugin - Version 2.0-alpha-1 ** Bug * [ARCHETYPE-82] - add-groups doesn't create archetype.xml * [ARCHETYPE-83] - archetypeng:create crashes with java.lang.ClassNotFoundException: org.apache.maven.plugin.resource.loader.ProjectResourceLoader * [ARCHETYPE-84] - need a way to preserve the java package in create-from-project * [ARCHETYPE-87] - create-from-project replaces too many things in the pom with variables * [ARCHETYPE-88] - sometimes add-groups fails when there is a pom present * [ARCHETYPE-90] - all the contents of an archetype shouldn't be processed by velocity during creation * [ARCHETYPE-91] - create is prompting for a package * [ARCHETYPE-93] - archetypeng:create loop forever when the selected group contains no archetype * [ARCHETYPE-94] - Archetype not registered when installed in local repository * [ARCHETYPE-97] - section is missing after using create-from-project * [ARCHETYPE-98] - parents in modules are not always correctly updated * [ARCHETYPE-99] - child module is getting replaced with parent artifactId and groupId * [ARCHETYPE-100] - sibling dependencies are not updated * [ARCHETYPE-103] - acrchetype.properties should be in /target not root * [ARCHETYPE-104] - module name changed for unknown reason * [ARCHETYPE-105] - not able to create from project with sibling-dependencies test project * [ARCHETYPE-121] - build don't works on windows and jdk1.4 ** Improvement * [ARCHETYPE-114] - NG code should not depend on Maven 2.1 ** New Feature * [ARCHETYPE-95] - Provide creation of partial archetypes in create-from-project ** Task * [ARCHETYPE-72] - Generate standard archetypes from real projects Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released
The Maven team is pleased to announce the release of the Maven Archetype Plugin, version 2.0-alpha-1 You can use it by calling mvn archetype:create Release Notes - Maven 2.x Archetype Plugin - Version 2.0-alpha-1 ** Bug * [ARCHETYPE-82] - add-groups doesn't create archetype.xml * [ARCHETYPE-83] - archetypeng:create crashes with java.lang.ClassNotFoundException: org.apache.maven.plugin.resource.loader.ProjectResourceLoader * [ARCHETYPE-84] - need a way to preserve the java package in create-from-project * [ARCHETYPE-87] - create-from-project replaces too many things in the pom with variables * [ARCHETYPE-88] - sometimes add-groups fails when there is a pom present * [ARCHETYPE-90] - all the contents of an archetype shouldn't be processed by velocity during creation * [ARCHETYPE-91] - create is prompting for a package * [ARCHETYPE-93] - archetypeng:create loop forever when the selected group contains no archetype * [ARCHETYPE-94] - Archetype not registered when installed in local repository * [ARCHETYPE-97] - section is missing after using create-from-project * [ARCHETYPE-98] - parents in modules are not always correctly updated * [ARCHETYPE-99] - child module is getting replaced with parent artifactId and groupId * [ARCHETYPE-100] - sibling dependencies are not updated * [ARCHETYPE-103] - acrchetype.properties should be in /target not root * [ARCHETYPE-104] - module name changed for unknown reason * [ARCHETYPE-105] - not able to create from project with sibling-dependencies test project * [ARCHETYPE-121] - build don't works on windows and jdk1.4 ** Improvement * [ARCHETYPE-114] - NG code should not depend on Maven 2.1 ** New Feature * [ARCHETYPE-95] - Provide creation of partial archetypes in create-from-project ** Task * [ARCHETYPE-72] - Generate standard archetypes from real projects Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javadoc plugin bug/issue reprised
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: Working vs. Build directory woes.
For what purpose? To use in a plugin, or a call to Antrun, or what? Wayne On 2/8/08, David C. Hicks <[EMAIL PROTECTED]> wrote: > Is there a way to get the current working directory (not the build > directory) from Maven in a property? > Thanks! > > > - > 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: release from a specific tag
Sorry, I was thinking you were using svn. Maybe you should convert ;) Yes, when I said the code is the same, I meant your project code minus the changes to the pom. So maybe you would need to do something like 1. checkout the tag 2. make a branch 3. check the code from the tag into the branch 4. make the changes to the pom. Then run your maven release. I agree this is not a very nice process. Benoit Decherf wrote: A tag is a fixed version, not a branch. So I can't make a release:prepare on a tag. This can probably be done in svn because there is no real difference between a tag and a branch, but that's not true in cvs. The "nightly x/x/x" and the "release x/x/x" are not the same code. The pom of a release has no SNAPSHOTs dependencies. Paul Gier wrote: I would think checking out from the tag, and then running release:prepare from that would work fine for you in this case. It will create another tag, but that shouldn't be a problem, since you probably want to keep one tag "nightly x/x/x" and then another tag "release x.x.x" even though they have basically the same code. There's nothing in the release plugin, as far as I know, that says you have to be working from trunk. Benoit Decherf wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote: But I don't want to create an official version every night. In the nightly version, there still have the -SNAPSHOT versions. So I can't use release:perform to do it. I realy need to execute the release:prepare from the nightly tag. All projects here ask for this feature. I think this is a very good feature to be able to release an "unofficial" version that is entirely tested. It seems strange that nobody has asked for this feature. All of you always create a version from the last commits files of the trunk (integration branch) ? Is it possible to make an evolution of the release plugin to support this ? Benoit Nicole Lacoste wrote: Hi Benoit, Yes I think so. Well I know you can release from a tag made with the release prepare. The command is mvn release:perform -DconnectionUrl=scm:svn:file://your-url-here/tag-name Look at page 224 of better builds with maven for more details Nicole On 06/02/2008, Benoit Decherf <[EMAIL PROTECTED]> wrote: Hi, I think that we should be able to perform a release from an old nightly tag rather than do it always from the trunk : Every night functional tests run on a project A. On day "d" everything works, but after, I decide to add a feature and I broke the trunk. I'd like to be able to release the project in it's state of day "d" without losing the work I done. This could be useful in some cases. Is there already a way to do it ? Benoit - 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]
Working vs. Build directory woes.
Is there a way to get the current working directory (not the build directory) from Maven in a property? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with custom check in checkstyle plugin
Barrie Treloar wrote: On Feb 6, 2008 8:37 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Funny how things in the universe sometimes occur at the exact same time... Yesterday I completely rewrote the example about using custom checks for the Checkstyle plugin. It is now a complete example with all code necessary. It's not published yet, but you can (sort of) read it directly from svn [1] or you can check out the Checkstyle plugin and run 'mvn site' to build the docs yourself. [1] https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/site/apt/examples/custom-developed-checkstyle.apt Please update the packagenames.xml to be the same as the one from within the checkstyle jar. I got stung with a problem because the Header check is not listed on the checkstyle web page but is listed within the jar file. OK, since I took the example file from their site, I probably need to update as well. I'll look into it. Including a note on verifying the contents of the checkstyle's package.xml would also be a good idea. But otherwise looks good. Thanks for checking! -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plugin (prepare) doesn't update more than one dependencies in multi modules project
Hi Paul,
thank you for your answer.
I created a new issue in JIRA with a patch that resolve the problem (or what
I think to be a problem)
http://jira.codehaus.org/browse/MRELEASE-323
Now I can't attach a small test to the issue for time purpose, the release
is close :-(
When I have a few free time I'll attach a simple test to the issue.
Until than, if you want you can try to apply my patch and see if resolve
your problems. I created a patch against 2.0-beta-8 but runs also with the
tagged 2.0-beta-7 version.
Bye
Alex
Paul Gier wrote:
>
> Sorry this is not much help, but I haven't had good luck with getting the
> release plugin to update my snapshot dependencies either. So I always
> update
> them manually before doing a release. If you can create a jira issue for
> this
> (in the release plugin project) and attach a small test project to
> reproduce the
> problem, I'm sure someone will get around to take a look at this.
>
> alexsil wrote:
>> Hi all,
>> I have a project so structured:
>>
>> au au-business
>> |
>> |--- au-sistema
>>
>> Dependencies in au are:
>>
>> ...
>>
>>
>>
>> com.zucchetti.qweb.au
>> au-business
>> ${project.version}
>>
>>
>>
>>
>> com.zucchetti.qweb.framework
>> sistema
>> 03.00.02-SNAPSHOT
>>
>>
>> com.zucchetti.qweb.framework
>> business
>> 03.00.02-SNAPSHOT
>>
>>
>>
>> ...
>>
>> Dependencies in au-business are:
>> ...
>>
>>
>> com.zucchetti.qweb.framework
>> business
>>
>>
>> ...
>>
>> Dependencies in au-sistema are:
>> ...
>>
>>
>> com.zucchetti.qweb.au
>> au-business
>>
>>
>> com.zucchetti.qweb.framework
>> sistema
>>
>>
>> ...
>>
>> When I make a mvn release:clean release:prepare the plugin, correctly,
>> ask
>> me to resolve SNAPSHOTs dependencies. (framework-business &&
>> framework-sistema)
>> Unfortunatly at the end of the process only framework-sistema has been
>> modified, while framework-business no.
>> I've debuged the problem and I found that if I force the two dependencies
>> (framework-sistema, framework-business) in the parent pom (pom of "au")
>> all
>> run fine (also if the process to resolve SNAPSHOT dependencies get
>> prompted
>> tree times ... too much I say ...).
>> Is this the correct behavior ?
>> I hope no, becouse I should modify al my poms.
>>
>> Morever , the flag "updateDependencies=false" doesn't run. I think it has
>> not managed.
>>
>> Best regards
>> Alex
>>
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Release-plugin-%28prepare%29-doesn%27t--update-more-than-one-dependencies-in-multi-modules-project-tp15293510s177p15363730.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]
Javadoc plugin bug/issue reprised
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
Re: Circular project reference
Patrick Shea wrote: I just came across an interesting issue. I have a master pom with 40 or so sub projects depending on it, the pom itself was using a plugin which in turn depended on it. So these two were constantly rebuilding them self because of a dependency change detection. Since this was the master pom the entire project groups (40+ projects) were building all the time. Is there a way for continuum to detect circular references? Patrick We have a similar condition with the Maven plugins. The all have the same parent which uses several reporting plugins... We have solved this by adding a "reporting" profile. The circular references are put into the profile. They are only ever called if you specify 'mvn -Preporting ...' on the command line. -- Dennis Lundberg
Circular project reference
I just came across an interesting issue. I have a master pom with 40 or so sub projects depending on it, the pom itself was using a plugin which in turn depended on it. So these two were constantly rebuilding them self because of a dependency change detection. Since this was the master pom the entire project groups (40+ projects) were building all the time. Is there a way for continuum to detect circular references? Patrick
Email/jndi Glassfish
I have deployed Continuum 1.1 into Glassfish v2. I wish to send emails out via GMail and have created a custom JNDI entry as described elsewhere. Glassfish/JavaMail appears, however, to require a Factory class definintion. I guessed at mail.smtp.socketFactory but I get error: Can't get mail session for component 'java:comp/mail/Session' whereas the JNDI seems to be set up correctly except for the Factrory class. Any ideas? Thanks for any help. -- View this message in context: http://www.nabble.com/Email-jndi-Glassfish-tp15360829p15360829.html Sent from the Continuum - Users mailing list archive at Nabble.com.
Re: Generate PDF books from maven
Hello, just use this plugin http://code.google.com/p/docbkx-tools/ and check out the documentation page at http://www.agilejava.com/docbkx/docbkx-samples/html/manual.html. I think it is the cleaner solution when talking about maven and docbook. Regards, Cedric Pronzato - May the Moo force be with you, Said Mimil -- View this message in context: http://www.nabble.com/Generate-PDF-books-from-maven-tp15353500s177p15360491.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]
[SOLVED] RE: Attaching javadoc to a non-maven artefact
Thanks, the -Dclassifier worked. I tried the other suggestion of copying the jars to the maven repo, but it failed a checksum on downloading -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 06 February 2008 16:03 To: Maven Users List Subject: RE: Attaching javadoc to a non-maven artefact Use the -Dclassifier option of deploy:deploy-file [1]. As far as I know it's just another classifier of the same artifact. Hth, Nick Stolwijk [1] http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.htm l#classifier -Original Message- From: Richard Chamberlain [mailto:[EMAIL PROTECTED] Sent: Wed 2/6/2008 4:51 PM To: Maven Users List Subject: Attaching javadoc to a non-maven artefact Hey all, I've got a non maven artefact that i've added to my company repository with mvn deploy:deploy-file. However i also have the javadoc and would like to add it to the repo. mvn deploy:deploy-file seems to only handle one file, so i'm at a loss as to how to get the javadoc in the repo. Thanks, Rich - 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: Maven Concepts
That makes two of us Dhruva. Seriously guys thanks a lot. Great help. On Feb 8, 2008 9:46 PM, Dhruva Reddy <[EMAIL PROTECTED]> wrote: > This really clears things up--many thanks! > > > -- > Dhruva B. Reddy > Senior Associate of Technology, Level 2 | Sapient > > 25 1st Street > Cambridge, MA, 02141, USA > desk: +1 617 452 1900 > fax: +1 617 621 1300 > > www.sapient.com > > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, 07 February 2008 17:01 > To: Maven Users List > Subject: Re: Maven Concepts > > You've got it exactly right. > > Maven builds are usually oriented around the concept of a lifecycle, > which consists of phases in a specific order. Each phase has zero or > more mojos (usually called goals) bound to it. Each phase in the > lifecycle implies all of the phases that come before it. This allows > users to bind (or configure) different goals to different phases of > the build, then the standard phase names to run the build. The > default goals for a given type of project are also bound to the > lifecycle in this way, but behind the scenes, such that the user can > supplement these default goals using configurations in the pom.xml. > > So, if you have a jar project (jar), you might > have something like this: > > Phase Goals > --- > > validate(none) > initialize (none) > ... > compileorg.apache.maven.plugins:maven-compiler- > plugin:compile > ... > testorg.apache.maven.plugins:maven-surefire- > plugin:test > ... > package org.apache.maven.plugins:maven-jar-plugin:jar > ... > install org.apache.maven.plugins:maven-install- > plugin:install > ... > etc. > > Now, if you just want to compile your project, you simply call the > 'compile' phase, like this: > > mvn compile > > If you want to run the unit tests, call this: > > mvn test > > Note that in order to run unit tests, you must have compiled your > project's main sources. That's handled here, since the test phase is > later in the lifecycle than the compile phase...'test' implies > 'compile' and all the other phases (in order) that come before 'test'. > > On the other hand, Maven also supports certain one-off goals that are > usually meant to help manage the project build in certain special > cases, or give information about the build. One such example gives > you a glimpse of the POM after all inheritance and profile injection > has been completed: > > mvn help:effective-pom > > which is shorthand for: > > mvn org.apache.maven.plugins:maven-help-plugin:effective-pom > > > Hope that helps, > > -john > > On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: > > > I know this seems like a silly thing to post on here, but... > > > > What exactly is a goal and what is a phase? I can't find a good > > answer in the documentation and there's a lot of seemingly > > conflicting information out there. > > > > My current understanding is that a phase is a part of a lifecycle > > (process-resources, compile, etc). A goal is somewhat analogous to > > an ANT-task, but with a focus on what should happen, rather than > > how it is done. > > > > Can someone clear this up for me, giving examples? > > > > Thanks, > > Dhruva > > --- > John Casey > Committer and PMC Member, Apache Maven > mail: jdcasey at commonjava dot org > blog: http://www.ejlife.net/blogs/john > rss: http://feeds.feedburner.com/ejlife/john > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: War Overlays and resources filtering
Hi Olivier, Thanks for your suggestion. Unfortunately it's not working, so I have opened an issue : MWAR-143 ( http://jira.codehaus.org/browse/MWAR-143). You will find an example in attachment in order to reproduce the problem. Rémy
Re: Unable to send emails
On Feb 8, 2008 5:32 PM, Jakub Kozisek <[EMAIL PROTECTED]> wrote: > Yes, I restarted it severail times. > > As I mentioned earlier everything is working on another machine and that > made me think something is wrong with OS configuration. Are you on windows with an antivirus? In some case, javamail can have some issues with antivirus > > > Anybody having same problem? > > Regards, > > Jakub >
Re: Unable to send emails
Yes, I restarted it severail times. As I mentioned earlier everything is working on another machine and that made me think something is wrong with OS configuration. Anybody having same problem? Regards, Jakub
Re: Missing 'scm' element in the POM.
The structure in Subversion is:
myproj/pom.xml
myproj/subproj1/pom.xml
myproj/subproj2/pom.xml
with a module definition of:
subproj1
subproj2
So, the sub-modules are sub-projects of the root module in Subversion.
-Jan
On Feb 7, 2008 5:11 PM, Jan Nielsen <[EMAIL PROTECTED]> wrote:
> I do; the pom.xml is identical to my workstation pom.xml. And the same
> pom.xml works in Continuum 1.0.3.
>
>
> On Feb 7, 2008 3:03 PM, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> > do you have scm element defined in the pom stored in your svn?
> >
> > Emmanuel
> >
> >
> > On Feb 7, 2008 9:25 PM, Jan Nielsen <[EMAIL PROTECTED]> wrote:
> >
> > > In Continuum 1.1, installed as a WAR in GlassFish 9.1ur1 on Windows, I
> > > have a multi-module Maven 2 POM being uploaded with a POM Url:
> > >
> > > file:///c:/dev/myproj/trunk/pom.xml
> > >
> > > with appropriate username, password, "Defined by POM" project group,
> > > and a checked "load only root as recursive build" and the default
> > > build definition template ("Default"). I have enabled file scheme;
> > > svn.exe is part of the %PATH%; and the pom.xml has the following scm
> > > element (sub-modules do not have an SCM element):
> > >
> > >
> > >scm:svn:svn://xxx.xxx.xxx.xxx/myproj/trunk
> > >
> > >
> > > scm:svn:svn://xxx.xxx.xxx.xxx/myproj/trunk
> > >http://xxx.xxx.xxx/view/myproj/trunk/
> > >
> > >
> > > The build from CLI with Maven 2.0.8 works fine, including the site
> > > goal which uses the scm element data successfully in the StatScm
> > > plugin; and this POM is successfully executed by Continuum 1.0.3 on
> > > Tomcat 6.0 instance to build everything including the site goal which
> > > includes the StatScm plugin.
> > >
> > > I found a few relevant other posts like:
> > >
> > >
> > > http://www.nabble.com/trouble-adding-Maven-2.0-pom-td13778433.html#a13778433
> > >
> > > but in "myproj" is, in fact, in Subversion and the SCM URLs appear to
> > > be correct.
> > >
> > > Any ideas?
> > >
> > >
> > > Thanks,
> > >
> > > -Jan
> > >
> >
>
Re: Generate PDF books from maven
Paul Gier wrote : > Hi Julien, > Can you create a jira issue for the jboss maven-jdocbook-plugin with > some sample input? Here is the jira URL > (http://jira.jboss.com/jira/browse/MPJDOCBOOK). Then maybe we can get > it fixed. > > Tahnks! > > Julien Graglia wrote: >> What do you use to generate PDF books? >> I also have found the JBoss Plugin : maven-jdocbook-plugin >> (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't >> get correct result : i try to inject the docbook xml generated by doxia, >> but it is invalid for jdocbook plugin...I have made some hand made >> corrections to the xml... but the result is awfull... the result is awfull because the docboook xml file I use is invalid. the maven-jdocbook-plugin itself works! In fact, I have a pb with the doc-book xml generated by doxia-maven-plugin Here is the content of the generated file : Section Jetty Trygve Jettysdsdfsd.dfsdfsd. ... the element is NOT opened, and I have en error in line 1 whith the jboss plugin, or the docbkx-maven-plugin [INFO] [docbkx:generate-pdf] [INFO] Processing ref-guide.xml Error on line 1 column 55 of file:///opt/nc/iv4trunk_co/iv-books/target/generated-site/doc-book/ref-guide/ref-guide.xml: Error reported by XML parser: White spaces are required between publicId and systemId. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to transform ref-guide.xml. Embedded error: org.xml.sax.SAXParseException: White spaces are required between publicId and systemId. If i remove the first line, and add a elt, a pdf is generated... but it looks ugly... It seems to be that the doc-book format is not well implemented by the doc-book format of doxia-maven-plugin. In fact it is named "doxia-module-docbook-simple" (1) I have looked at the tests resources (2) of doxia-book : the expected result (3) is far away from what I have : http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd";> Test Book Chapter 1 first 3 lines of xml are good here only 1 bookinfo elt (i have one bookinfo at each chapter, and no book elt!) Lukas Theussl wrote : > > Unfortunately it only works with latest Maven-2.0.9-SNAPSHOT using > doxia-1.0-beta-1-SNAPSHOT... so you'll have to build everything > yourself if you want to try it. The FO module is also scheduled to > replace the deprecated iText in doxia book, but that's still a way > ahead... Well, I think I have to wait... thx! 1: https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-docbook-simple/ 2: https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-book/src/test/resources/ 3 : https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-book/src/test/resources/expected/doc-book/plexus-user-guide.xml -- Julien Graglia
RE: Maven Concepts
This really clears things up--many thanks! -- Dhruva B. Reddy Senior Associate of Technology, Level 2 | Sapient 25 1st Street Cambridge, MA, 02141, USA desk: +1 617 452 1900 fax: +1 617 621 1300 www.sapient.com -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Thursday, 07 February 2008 17:01 To: Maven Users List Subject: Re: Maven Concepts You've got it exactly right. Maven builds are usually oriented around the concept of a lifecycle, which consists of phases in a specific order. Each phase has zero or more mojos (usually called goals) bound to it. Each phase in the lifecycle implies all of the phases that come before it. This allows users to bind (or configure) different goals to different phases of the build, then the standard phase names to run the build. The default goals for a given type of project are also bound to the lifecycle in this way, but behind the scenes, such that the user can supplement these default goals using configurations in the pom.xml. So, if you have a jar project (jar), you might have something like this: Phase Goals --- validate(none) initialize (none) ... compileorg.apache.maven.plugins:maven-compiler- plugin:compile ... testorg.apache.maven.plugins:maven-surefire- plugin:test ... package org.apache.maven.plugins:maven-jar-plugin:jar ... install org.apache.maven.plugins:maven-install- plugin:install ... etc. Now, if you just want to compile your project, you simply call the 'compile' phase, like this: mvn compile If you want to run the unit tests, call this: mvn test Note that in order to run unit tests, you must have compiled your project's main sources. That's handled here, since the test phase is later in the lifecycle than the compile phase...'test' implies 'compile' and all the other phases (in order) that come before 'test'. On the other hand, Maven also supports certain one-off goals that are usually meant to help manage the project build in certain special cases, or give information about the build. One such example gives you a glimpse of the POM after all inheritance and profile injection has been completed: mvn help:effective-pom which is shorthand for: mvn org.apache.maven.plugins:maven-help-plugin:effective-pom Hope that helps, -john On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote: > I know this seems like a silly thing to post on here, but... > > What exactly is a goal and what is a phase? I can't find a good > answer in the documentation and there's a lot of seemingly > conflicting information out there. > > My current understanding is that a phase is a part of a lifecycle > (process-resources, compile, etc). A goal is somewhat analogous to > an ANT-task, but with a focus on what should happen, rather than > how it is done. > > Can someone clear this up for me, giving examples? > > Thanks, > Dhruva --- John Casey Committer and PMC Member, Apache Maven mail: jdcasey at commonjava dot org blog: http://www.ejlife.net/blogs/john rss: http://feeds.feedburner.com/ejlife/john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
discuss: module paths
Every example I've seen for multi-module projects uses relative paths.
What are some of the drawbacks that would make absolute paths a poor
design choice, as in the following example?
C:/project
${root.dir}/module1/sub-module1/artifact1a
${root.dir}/module1/sub-module1/artifact1b
Thanks
Robert Egan
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.
Re: Javadoc plugin issues again
Yeah that works (and I've tried that), but why doesn't mvn javadoc:javadoc work? Am I reading the javadoc plugin documentation incorrectly. That should work if I JUST want to generate javadoc. -aps On Feb 8, 2008 10:30 AM, Damien Lecan <[EMAIL PROTECTED]> wrote: > mvn site ? > > Damien > > 2008/2/8, Alexander Sack <[EMAIL PROTECTED]>: > > Any chance, does anyone have a POM snippet that has javadoc working? > > -aps > > > > On Feb 7, 2008 2:44 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > > > > Hi All: > > > I'm trying to wrap up our build process and I'm having again more > trouble > > > with the javadoc plugin (v2.3). I have a multi module project > organized: > > > > > > pom.xml > > > module1 > > > pom.xml > > > module2 > > > pom.xml > > > etc. > > > > > > In module1 (first one compiled, etc.), I have a simple pom that > specifies > > > some dependencies for a jar module. I've added to it: > > > > > > > > > > > > > > > org.apache.maven.plugins > > > maven-javadoc-plugin > > > > > > true > > > true > > > > > > > > > > > > > > > > > > Note: FAQ mentions debug, Usage mentions verbose, I included both > > > > > > When I run mvn javadoc:javadoc, Velocity starts but NO javadoc is > > > generated. Do I have to specify something in the configuration that > > > translates to the @packages that gets passed to javadoc commandline > Maven > > > executes? Has anyone seen this before (the build is completely > SUCCESSFUL > > > minus the javadoc stage). > > > > > > I faced this once before and had to use the "site" build phase to get > it > > > to go but I really want to avoid it (it generates a lot of unnecessary > > > files). > > > > > > Thanks! > > > > > > -aps > > > > > > -- > > > "What lies behind us and what lies in front of us is of little concern > to > > > what lies within us." -Ralph Waldo Emerson > > > > > > > > > > > -- > > "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] > > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
Re: Javadoc plugin issues again
mvn site ? Damien 2008/2/8, Alexander Sack <[EMAIL PROTECTED]>: > Any chance, does anyone have a POM snippet that has javadoc working? > -aps > > On Feb 7, 2008 2:44 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > > > Hi All: > > I'm trying to wrap up our build process and I'm having again more trouble > > with the javadoc plugin (v2.3). I have a multi module project organized: > > > > pom.xml > > module1 > > pom.xml > > module2 > > pom.xml > > etc. > > > > In module1 (first one compiled, etc.), I have a simple pom that specifies > > some dependencies for a jar module. I've added to it: > > > > > > > > > > org.apache.maven.plugins > > maven-javadoc-plugin > > > > true > > true > > > > > > > > > > > > Note: FAQ mentions debug, Usage mentions verbose, I included both > > > > When I run mvn javadoc:javadoc, Velocity starts but NO javadoc is > > generated. Do I have to specify something in the configuration that > > translates to the @packages that gets passed to javadoc commandline Maven > > executes? Has anyone seen this before (the build is completely SUCCESSFUL > > minus the javadoc stage). > > > > I faced this once before and had to use the "site" build phase to get it > > to go but I really want to avoid it (it generates a lot of unnecessary > > files). > > > > Thanks! > > > > -aps > > > > -- > > "What lies behind us and what lies in front of us is of little concern to > > what lies within us." -Ralph Waldo Emerson > > > > > > -- > "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: Generate PDF books from maven
Hi Julien, Can you create a jira issue for the jboss maven-jdocbook-plugin with some sample input? Here is the jira URL (http://jira.jboss.com/jira/browse/MPJDOCBOOK). Then maybe we can get it fixed. Tahnks! Julien Graglia wrote: What do you use to generate PDF books? I'am using doxia-maven-plugin to generate html books, but the pdf format is 'deprecated' because it is generated by iText and iText no longer support pdf output. (http://maven.apache.org/doxia/modules/index.html). I have pb with UTF 8 encoding of french pages...(it is a known pb of iText...) I have read that from the doc-book output of doxia, I can generate a PDF book but I don't have found how...docbook seems very "dark" to me : need a xsltranslator , how? not a word of doxia site... I also have found the JBoss Plugin : maven-jdocbook-plugin (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't get correct result : i try to inject the docbook xml generated by doxia, but it is invalid for jdocbook plugin...I have made some hand made corrections to the xml... but the result is awfull... Well, I try many things, but did not found ONE way to generate a pdf from maven What do you use? and how? Thanks! May be it's just a dream? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plugin (prepare) doesn't update more than one dependencies in multi modules project
Sorry this is not much help, but I haven't had good luck with getting the
release plugin to update my snapshot dependencies either. So I always update
them manually before doing a release. If you can create a jira issue for this
(in the release plugin project) and attach a small test project to reproduce the
problem, I'm sure someone will get around to take a look at this.
alexsil wrote:
Hi all,
I have a project so structured:
au au-business
|
|--- au-sistema
Dependencies in au are:
...
com.zucchetti.qweb.au
au-business
${project.version}
com.zucchetti.qweb.framework
sistema
03.00.02-SNAPSHOT
com.zucchetti.qweb.framework
business
03.00.02-SNAPSHOT
...
Dependencies in au-business are:
...
com.zucchetti.qweb.framework
business
...
Dependencies in au-sistema are:
...
com.zucchetti.qweb.au
au-business
com.zucchetti.qweb.framework
sistema
...
When I make a mvn release:clean release:prepare the plugin, correctly, ask
me to resolve SNAPSHOTs dependencies. (framework-business &&
framework-sistema)
Unfortunatly at the end of the process only framework-sistema has been
modified, while framework-business no.
I've debuged the problem and I found that if I force the two dependencies
(framework-sistema, framework-business) in the parent pom (pom of "au") all
run fine (also if the process to resolve SNAPSHOT dependencies get prompted
tree times ... too much I say ...).
Is this the correct behavior ?
I hope no, becouse I should modify al my poms.
Morever , the flag "updateDependencies=false" doesn't run. I think it has
not managed.
Best regards
Alex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: release from a specific tag
A tag is a fixed version, not a branch. So I can't make a release:prepare on a tag. This can probably be done in svn because there is no real difference between a tag and a branch, but that's not true in cvs. The "nightly x/x/x" and the "release x/x/x" are not the same code. The pom of a release has no SNAPSHOTs dependencies. Paul Gier wrote: I would think checking out from the tag, and then running release:prepare from that would work fine for you in this case. It will create another tag, but that shouldn't be a problem, since you probably want to keep one tag "nightly x/x/x" and then another tag "release x.x.x" even though they have basically the same code. There's nothing in the release plugin, as far as I know, that says you have to be working from trunk. Benoit Decherf wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote: But I don't want to create an official version every night. In the nightly version, there still have the -SNAPSHOT versions. So I can't use release:perform to do it. I realy need to execute the release:prepare from the nightly tag. All projects here ask for this feature. I think this is a very good feature to be able to release an "unofficial" version that is entirely tested. It seems strange that nobody has asked for this feature. All of you always create a version from the last commits files of the trunk (integration branch) ? Is it possible to make an evolution of the release plugin to support this ? Benoit Nicole Lacoste wrote: Hi Benoit, Yes I think so. Well I know you can release from a tag made with the release prepare. The command is mvn release:perform -DconnectionUrl=scm:svn:file://your-url-here/tag-name Look at page 224 of better builds with maven for more details Nicole On 06/02/2008, Benoit Decherf <[EMAIL PROTECTED]> wrote: Hi, I think that we should be able to perform a release from an old nightly tag rather than do it always from the trunk : Every night functional tests run on a project A. On day "d" everything works, but after, I decide to add a feature and I broke the trunk. I'd like to be able to release the project in it's state of day "d" without losing the work I done. This could be useful in some cases. Is there already a way to do it ? Benoit - 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: release from a specific tag
I would think checking out from the tag, and then running release:prepare from that would work fine for you in this case. It will create another tag, but that shouldn't be a problem, since you probably want to keep one tag "nightly x/x/x" and then another tag "release x.x.x" even though they have basically the same code. There's nothing in the release plugin, as far as I know, that says you have to be working from trunk. Benoit Decherf wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote: But I don't want to create an official version every night. In the nightly version, there still have the -SNAPSHOT versions. So I can't use release:perform to do it. I realy need to execute the release:prepare from the nightly tag. All projects here ask for this feature. I think this is a very good feature to be able to release an "unofficial" version that is entirely tested. It seems strange that nobody has asked for this feature. All of you always create a version from the last commits files of the trunk (integration branch) ? Is it possible to make an evolution of the release plugin to support this ? Benoit Nicole Lacoste wrote: Hi Benoit, Yes I think so. Well I know you can release from a tag made with the release prepare. The command is mvn release:perform -DconnectionUrl=scm:svn:file://your-url-here/tag-name Look at page 224 of better builds with maven for more details Nicole On 06/02/2008, Benoit Decherf <[EMAIL PROTECTED]> wrote: Hi, I think that we should be able to perform a release from an old nightly tag rather than do it always from the trunk : Every night functional tests run on a project A. On day "d" everything works, but after, I decide to add a feature and I broke the trunk. I'd like to be able to release the project in it's state of day "d" without losing the work I done. This could be useful in some cases. Is there already a way to do it ? Benoit - 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: Re: Unable to send emails
in the extracted apps is enough. Do you have restarted your continuum? Emmanuel On Feb 8, 2008 3:53 PM, Jakub Kozisek <[EMAIL PROTECTED]> wrote: > Thank you for your answer! > > Problem is that I already set "from-mailbox" and "from-name" in > application.xml - in both "apps/continuum-plexus-application-1.1.jar" and > also in extracted "apps/continuum" and it is not working. Any other ideas > or > it is for sure that Continuum is not getting mailbox setting from > application.xml? > > Regards, > > Jakub Kozisek >
Re: Re: Unable to send emails
Thank you for your answer! Problem is that I already set "from-mailbox" and "from-name" in application.xml - in both "apps/continuum-plexus-application-1.1.jar" and also in extracted "apps/continuum" and it is not working. Any other ideas or it is for sure that Continuum is not getting mailbox setting from application.xml? Regards, Jakub Kozisek
Re: Javadoc plugin issues again
Any chance, does anyone have a POM snippet that has javadoc working? -aps On Feb 7, 2008 2:44 PM, Alexander Sack <[EMAIL PROTECTED]> wrote: > Hi All: > I'm trying to wrap up our build process and I'm having again more trouble > with the javadoc plugin (v2.3). I have a multi module project organized: > > pom.xml > module1 > pom.xml > module2 > pom.xml > etc. > > In module1 (first one compiled, etc.), I have a simple pom that specifies > some dependencies for a jar module. I've added to it: > > > > > org.apache.maven.plugins > maven-javadoc-plugin > > true > true > > > > > > Note: FAQ mentions debug, Usage mentions verbose, I included both > > When I run mvn javadoc:javadoc, Velocity starts but NO javadoc is > generated. Do I have to specify something in the configuration that > translates to the @packages that gets passed to javadoc commandline Maven > executes? Has anyone seen this before (the build is completely SUCCESSFUL > minus the javadoc stage). > > I faced this once before and had to use the "site" build phase to get it > to go but I really want to avoid it (it generates a lot of unnecessary > files). > > Thanks! > > -aps > > -- > "What lies behind us and what lies in front of us is of little concern to > what lies within us." -Ralph Waldo Emerson > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
RE: Updating M2_HOME/conf/settings.xml
Hi Matt,
You may need a way for developers to override this, so they can work on old
versions. Also, be carefull that your overrides to settings.xml doesn't effect
vanilla maven builds -- say someone wants to build some tool they downloaded
from the web.
I don't claim that this is best, but what I've done is to create three copies
of settings.xml called dev.xml, staged.xml, and cert.xml to reflect the
settings for the three different groups who do builds. I store these settings
files separate from the maven install directories. I then created a build
script which invokes maven with the -s switch passing the correct settings
file. So, when a developer runs the build script, mvn -s
/shared/maven_utils/2.0/dev.xml is executed.
Hope this helps,
Christopher Helck
-Original Message-
From: Matthew Tordoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 07, 2008 10:11 AM
To: users@maven.apache.org
Subject: Re: Updating M2_HOME/conf/settings.xml
Hi Stefan,
The reason that we don't have one master POM as a parent to all other POMs is
that we have multiple different products, all under independant source control.
These products may want to have differing master POMs. Also, we will be
overriding the central repository location in the global settings.xml. Without
the repository you won't be able to retrieve the master POM.
The solution we have decided upon is to use a software distribution management
tool from Symantec (LiveState) which can be used to automatically push the
latest configuration for Maven directly onto developers machines (even upgrade
Maven itself if necessary). This requires no manual work to be done from the
developers point of view.
Matt
-Original Message-
From: VUB Stefan Seidel [mailto:[EMAIL PROTECTED]
Sent: 07 February 2008 13:42
To: Maven Users List
Subject: Re: Updating M2_HOME/conf/settings.xml
Put /conf/settings.xml on a shared drive, or replace it with
a symlink to a shared drive.
Why do you need to change the settings.xml anyway? Could it not be done in a
master pom that is the parent to all other poms? Then you can simply deploy the
master pom and you're done.
Stefan
Matthew Tordoff wrote:
> Hi all,
>
> I just wondered if anyone has any best practises for updating the global
> settings.xml in Maven. I have considered checking the conf folder into SVN,
> or even potentially checking the whole maven install into SVN, then when
> changes are made send out an email and people can just do an SVN update to
> pick up the changes. The only disadvantage of this process is that it relies
> on people reading their mail and kicking off the update. I would preferably
> like a method of automatically publishing changes which would automatically
> update all developers machines.
>
> Any thoughts around this would be greatly appreciated.
>
> Regards,
>
> Matt
>
> P.S. I would also be interested on your views regarding checking in solely
> the settings.xml file into version control, vs checking in the whole install.
>
> _
> Free games, great prizes - get gaming at Gamesbox.
> http://www.searchgamesbox.com
--
best regards,
Stefan Seidel
software developer
VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel.+49 (341) 9 60 50 07
fax.+49 (341) 9 60 50 92
mail. [EMAIL PROTECTED]
web.www.vub.de
HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Share what Santa brought you
https://www.mycooluncool.com
**
This communication and all information (including, but not limited to,
market prices/levels and data) contained therein (the "Information") is
for informational purposes only, is confidential, may be legally
privileged and is the intellectual property of ICAP plc and its affiliates
("ICAP") or third parties. No confidentiality or privilege is waived or
lost by any mistransmission. The Information is not, and should not
be construed as, an offer, bid or solicitation in relation to any
financial instrument or as an official confirmation of any transaction.
The Information is not warranted, including, but not limited, as to
completeness, timeliness or accuracy and is subject to change
without notice. ICAP assumes no liability for use or misuse of the
Information. All representations and warranties are expressly
disclaimed. The Information does not necessarily reflect the views of
ICAP. Access to the Information by anyone else other than the
recipient is unauthorized and any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it is proh
Re: RES: Referencing uniqe SNAPSHOT versions in POM
The repository contains some artifact at a/b/c/artifactid/SNAPSHOT/artifactid-20071218.132506-1.jar So I try to refer to that file with the following snippet. a.b.c artifactid SNAPSHOT When using SNAPSHOT it will resolve to the latest version of such file given above. But how to refer to an older version? Thanks for your help. On Friday 08 February 2008 14:07:20 Dário Luís Coneglian Oliveros wrote: > Please attach your pom file so I can take a look at it. > > Dário > > -Mensagem original- > De: Marco Bakera [mailto:[EMAIL PROTECTED] > Enviada em: sexta-feira, 8 de fevereiro de 2008 11:01 > Para: users@maven.apache.org > Assunto: Re: Referencing uniqe SNAPSHOT versions in POM > > > Sorry neither your nor Dario's solution solves the problem. :( > > However thanks for your help so far. > > On Friday 08 February 2008 13:50:17 nicolas de loof wrote: > > Simply use > > > > 20071218.1329060-1 > > > > Maven will automatically detect this is a SNAPSHOT (using > > metadatas.xml in repo AFAIK) > > > > The latest (snapshot) release plugin accepts them as valid. You just > > have to ensure there will be available in future for your build to be > > reproductible (make a repo backup or use a corporate repo/proxy) > > > > Nico. > > > > 2008/2/8, Marco Bakera <[EMAIL PROTECTED]>: > > > Hey everybody! > > > > > > Sometime I find SNAPSHOT versions in the repository like > > > groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It > > > seems that this are SNAPSHOTS uniquely identifiable via some > > > identifier. > > > > > > But how can I refer to such a version from my dependency section in > > > my pom? > > > > > > > > > Thanks for help and greetings, > > > Marco. signature.asc Description: This is a digitally signed message part.
Re: Generate PDF books from maven
Just FYI, doxia-1.0-beta-1 will include a FO sink [1] and we are currently working on a pdf plugin in the maven sandbox [2]. Unfortunately it only works with latest Maven-2.0.9-SNAPSHOT using doxia-1.0-beta-1-SNAPSHOT... so you'll have to build everything yourself if you want to try it. The FO module is also scheduled to replace the deprecated iText in doxia book, but that's still a way ahead... Cheers, -Lukas [1] https://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-fo/ [2] https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-pdf-plugin/ Julien Graglia wrote: What do you use to generate PDF books? I'am using doxia-maven-plugin to generate html books, but the pdf format is 'deprecated' because it is generated by iText and iText no longer support pdf output. (http://maven.apache.org/doxia/modules/index.html). I have pb with UTF 8 encoding of french pages...(it is a known pb of iText...) I have read that from the doc-book output of doxia, I can generate a PDF book but I don't have found how...docbook seems very "dark" to me : need a xsltranslator , how? not a word of doxia site... I also have found the JBoss Plugin : maven-jdocbook-plugin (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't get correct result : i try to inject the docbook xml generated by doxia, but it is invalid for jdocbook plugin...I have made some hand made corrections to the xml... but the result is awfull... Well, I try many things, but did not found ONE way to generate a pdf from maven What do you use? and how? Thanks! May be it's just a dream? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generate PDF books from maven
On Feb 8, 2008 4:27 AM, Julien Graglia <[EMAIL PROTECTED]> wrote: > What do you use to generate PDF books? Here's one option based on DocBook: http://code.google.com/p/docbkx-tools/ There's also some work happening in the sandbox on a PDF plugin like Maven 1 used to have, which converts the apt and xdoc source into a PDF. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generate PDF books from maven
You can look at the RichFaces (http://labs.jboss.com/jbossrichfaces/) project, I know they generate PDF with Maven, but I don't know why plugin they use. Regards Jeff On Feb 8, 2008 12:27 PM, Julien Graglia <[EMAIL PROTECTED]> wrote: > What do you use to generate PDF books? > > I'am using doxia-maven-plugin to generate html books, but the pdf format > is 'deprecated' because it is generated by iText and iText no longer > support pdf output. (http://maven.apache.org/doxia/modules/index.html). > I have pb with UTF 8 encoding of french pages...(it is a known pb of > iText...) > > I have read that from the doc-book output of doxia, I can generate a PDF > book but I don't have found how...docbook seems very "dark" to me : need > a xsltranslator , how? not a word of doxia site... > > I also have found the JBoss Plugin : maven-jdocbook-plugin > (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't > get correct result : i try to inject the docbook xml generated by doxia, > but it is invalid for jdocbook plugin...I have made some hand made > corrections to the xml... but the result is awfull... > > > Well, I try many things, but did not found ONE way to generate a pdf > from maven > > What do you use? and how? Thanks! > May be it's just a dream? > > -- > Julien Graglia > > > > Extract of my pom : > > > > > >org.jboss.maven.plugins >maven-jdocbook-plugin >2.0.0 >true > > >install > >generate > > > > > > >true > > > > >html > > >pdf > > >ref-guide.xml > > > > > > > >org.apache.maven.doxia >doxia-maven-plugin >1.0-alpha-10 > > >pre-site > >render-books > > > > > > >src/books/ref-guide/ >src/books/ref-guide.xml > > > >xdoc > > >xhtml > > >doc-book > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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
RES: Referencing uniqe SNAPSHOT versions in POM
Please attach your pom file so I can take a look at it. Dário -Mensagem original- De: Marco Bakera [mailto:[EMAIL PROTECTED] Enviada em: sexta-feira, 8 de fevereiro de 2008 11:01 Para: users@maven.apache.org Assunto: Re: Referencing uniqe SNAPSHOT versions in POM Sorry neither your nor Dario's solution solves the problem. :( However thanks for your help so far. On Friday 08 February 2008 13:50:17 nicolas de loof wrote: > Simply use > > 20071218.1329060-1 > > Maven will automatically detect this is a SNAPSHOT (using > metadatas.xml in repo AFAIK) > > The latest (snapshot) release plugin accepts them as valid. You just > have to ensure there will be available in future for your build to be > reproductible (make a repo backup or use a corporate repo/proxy) > > Nico. > > 2008/2/8, Marco Bakera <[EMAIL PROTECTED]>: > > Hey everybody! > > > > Sometime I find SNAPSHOT versions in the repository like > > groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It > > seems that this are SNAPSHOTS uniquely identifiable via some > > identifier. > > > > But how can I refer to such a version from my dependency section in > > my pom? > > > > > > Thanks for help and greetings, > > Marco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Referencing uniqe SNAPSHOT versions in POM
Sorry neither your nor Dario's solution solves the problem. :( However thanks for your help so far. On Friday 08 February 2008 13:50:17 nicolas de loof wrote: > Simply use > > 20071218.1329060-1 > > Maven will automatically detect this is a SNAPSHOT (using metadatas.xml in > repo AFAIK) > > The latest (snapshot) release plugin accepts them as valid. You just have > to ensure there will be available in future for your build to be > reproductible (make a repo backup or use a corporate repo/proxy) > > Nico. > > 2008/2/8, Marco Bakera <[EMAIL PROTECTED]>: > > Hey everybody! > > > > Sometime I find SNAPSHOT versions in the repository like > > groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems > > that > > this are SNAPSHOTS uniquely identifiable via some identifier. > > > > But how can I refer to such a version from my dependency section in my > > pom? > > > > > > Thanks for help and greetings, > > Marco. signature.asc Description: This is a digitally signed message part.
Re: Referencing uniqe SNAPSHOT versions in POM
Simply use 20071218.1329060-1 Maven will automatically detect this is a SNAPSHOT (using metadatas.xml in repo AFAIK) The latest (snapshot) release plugin accepts them as valid. You just have to ensure there will be available in future for your build to be reproductible (make a repo backup or use a corporate repo/proxy) Nico. 2008/2/8, Marco Bakera <[EMAIL PROTECTED]>: > > Hey everybody! > > Sometime I find SNAPSHOT versions in the repository like > groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems > that > this are SNAPSHOTS uniquely identifiable via some identifier. > > But how can I refer to such a version from my dependency section in my > pom? > > > Thanks for help and greetings, > Marco. > >
RES: Referencing uniqe SNAPSHOT versions in POM
In the same way as it were non-unique: just use x.y-SNAPSHOT for instance. If do not want unique snasphot version in your repo, you'll have to add the following to distributionManagement section: ... false ... Dário -Mensagem original- De: Marco Bakera [mailto:[EMAIL PROTECTED] Enviada em: sexta-feira, 8 de fevereiro de 2008 09:41 Para: Maven Users Assunto: Referencing uniqe SNAPSHOT versions in POM Hey everybody! Sometime I find SNAPSHOT versions in the repository like groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems that this are SNAPSHOTS uniquely identifiable via some identifier. But how can I refer to such a version from my dependency section in my pom? Thanks for help and greetings, Marco. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Referencing uniqe SNAPSHOT versions in POM
Hey everybody! Sometime I find SNAPSHOT versions in the repository like groupid/artifactid/SNAPSHOT/artifactid-20071218.1329060-1.jar. It seems that this are SNAPSHOTS uniquely identifiable via some identifier. But how can I refer to such a version from my dependency section in my pom? Thanks for help and greetings, Marco. signature.asc Description: This is a digitally signed message part.
Generate PDF books from maven
What do you use to generate PDF books? I'am using doxia-maven-plugin to generate html books, but the pdf format is 'deprecated' because it is generated by iText and iText no longer support pdf output. (http://maven.apache.org/doxia/modules/index.html). I have pb with UTF 8 encoding of french pages...(it is a known pb of iText...) I have read that from the doc-book output of doxia, I can generate a PDF book but I don't have found how...docbook seems very "dark" to me : need a xsltranslator , how? not a word of doxia site... I also have found the JBoss Plugin : maven-jdocbook-plugin (http://labs.jboss.com/maven-jdocbook-plugin/) but, here again, I didn't get correct result : i try to inject the docbook xml generated by doxia, but it is invalid for jdocbook plugin...I have made some hand made corrections to the xml... but the result is awfull... Well, I try many things, but did not found ONE way to generate a pdf from maven What do you use? and how? Thanks! May be it's just a dream? -- Julien Graglia Extract of my pom : org.jboss.maven.plugins maven-jdocbook-plugin 2.0.0 true install generate true html pdf ref-guide.xml org.apache.maven.doxia doxia-maven-plugin 1.0-alpha-10 pre-site render-books src/books/ref-guide/ src/books/ref-guide.xml xdoc xhtml doc-book - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem in building some sample java srcs
hi all
am beginner to maven tool
am using maven1.1 version
am trying to build some java srcs using this tool
by maven java:compile
my project.xml is as follows
--
daven
1.0
${basedir}/src/java
but wen i try to build am getting some dependencies missing
commons-jelly:commons-jelly-tags-jsl:1.0:jar
commons-jelly:commons-jelly-tags-log:1.0:jar
commons-jelly:commons-jelly-tags-velocity:1.0:jar
org.apache.velocity:velocity:1.5:jar
velocity-dvsl:velocity-dvsl:0.45:jar
commons-jelly:commons-jelly-tags-fmt:1.0:jar
org.apache.maven.scm:maven-scm-api:1.0-beta-2:jar
org.apache.maven.scm:maven-scm-provider-cvs:1.0-beta-2:jar
org.apache.maven.scm:maven-scm-provider-svn:1.0-beta-2:jar
org.apache.maven.scm:maven-scm-provider-perforce:1.0-beta-2:jar
org.apache.maven.scm:maven-scm-provider-clearcase:1.0-beta-2:ja
org.apache.maven.scm:maven-scm-provider-starteam:1.0-beta-2:jar
plz help me out
thanks
--
View this message in context:
http://www.nabble.com/problem-in-building-some-sample-java-srcs-tp15353432s177p15353432.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: release from a specific tag
Kalle Korhonen wrote: Well, maybe you have a valid use case, but I don't think there's any support for it. How do you create a nightly tag then? Couldn't you just run release:prepare nightly, then run integration tests on the newly created tag, and if succeeds, perform the release, otherwise abandon the tag. I don't see a difference between a nightly tag and an "official tag" - you could just use minor/micro version numbers to differentiate between "official releases" and nightlies. Alternatively, if you use svn, you should in principle be able to use revision number for this, but I don't think there's any way to instruct Maven to checkout specific revision for release:prepare rather than always using the head. A nightly version is like a snapshot. It have to be deleted after some days. It is just here to check that we are able to create valid version every night and that nothing is broken. The nightly tag process is done by continuum in our process. I'm agree with you that revision number in svn could solve our problem, but we need in all case to be able to create a release from an older revision number and not the trunk (And anyway we are not yet using svn :( ). So it would be great to add 1 option to maven release:prepare (-DfromTag). If this option is set, maven should create a branch from this version, checkout this branch and execute the standard release process from it. This also mean that scm:branch should be able to create a branch from an older tag. (I think it is not possible to do it for the moment). And as you said, it will be great to be able to create a release from a specific revision number, so we wouldn't have to tag every night (for the day we will migrate to svn:) ) I think that I could take some time to work on this improvement if you accept it. Benoit. Kalle On Feb 7, 2008 2:40 AM, Benoit Decherf <[EMAIL PROTECTED]> wrote: I'm not sure that this it's specific to our process (If this is the case, we should probably change it :) ). I don't think that is possible to have always a clean trunk/branch. Let me explain our process: Each developer commit their changes on the trunk. Each hour, continuum check for changes and package the components(and execute the unit test). Each night project is tagged (nightly tag) and the packages are installed on a dev plateform and automatics tests are executed. This can last 3 hours. So, I agree with you that if a unit test fails, the developer have to clean it (This shouldn't happen because tests should be executed before commit). But the integration tests that last 3 hours can't be executed on each commit, so something can be broken for several days because of a regression. This also occurs at maven. Additionaly, when performing (prepare) a release, It should be great to be sure that the integration tests passed. So it can be useful to be able to prepare/perform a release from a nightly tag. Benoit Kalle Korhonen wrote: Ah ok, I see what you mean, but I think it's specific to your process. I'd assume that most projects operate so they require that the trunk/branch builds cleanly, rather than releasing from a specific time point/version/label. In your case, it'd mean reverting the trunk to 04 feb, then doing the release. In the meantime 05 feb would continue in branch or with local copies only. I believe it's also common practice to require the trunk builds to succeed. In our development process, we try not to prevent build failures but to minimize the time the build remains in broken state, with whatever means necessary (in some cases, reverting to previous state). Kalle On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote: Image that we are working on the trunk. Every night a nightly snapshot is created and deploy on a test servers and automatic tests are run (they can last 4hours for a project). on date 04 feb. every tests passed. on date 05 feb. some tests are broken. But on 06 feb we want to make a release (to install in prod). The dev started on 05 feb are not finished, and so the nightly of 04 feb should be released. To do so, I suppose that release:prepare should be executed from the nightly tag of 4 feb to remove all snapshots dependencies, tag the release with an official tag, etc... The release prepare should create a branch from this tag to do it ? Benoit Kalle Korhonen wrote: I don't understand what you are asking. release:perform doesn't do anything else but runs deploy (and site-deploy) on the newly created tag; after release:prepare, the release is already cut. If you want snapshots, why don't you just deploy uniquely versioned snapshots nightly? Kalle On 2/7/08, Benoit Decherf <[EMAIL PROTECTED]> wrote: But I don't want to create an official version every night. In the nightly version, there still
Re: Maven Concepts
Stephen Connolly <[EMAIL PROTECTED]> schrieb: > Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will not > re-download it. Absolutely. Never overwrite an existing deployed file except when it has SNAPSHOT in the version. Builds should be repeatable, ie you should be able to compile something today, then compile it again next week and get the same result. This means that stuff deployed to a repository should never change. The only exception is SNAPSHOT versions; when a project depends on one of these, then it is explicitly acknowledging that repeatable builds are not possible. One of the things the release plugin does is check that there are no SNAPSHOT dependencies anywere; if there are then it refuses to continue with the release process as the release is not repeatable. Of course using the release plugin is not mandatory, but that particular check is a very good idea. And because Maven assumes people never overwrite non-snapshot files, it never bothers to check for newer ones. Only with SNAPSHOTs does maven look for newer versions, on an "every time", "daily" or "weekly" basis as configured. Regards, Simon - 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] > >
performance issue of built-in container
hi, the archiva responding sometimes is a bit slow (especially deploy through webdav and browsing inside web-admin area). i know 'a bit slow' is very unprecise but i just want to ask whether performance generally could be speeded up when switching from built in to another container like tomcat? thanks. - manuel aldana aldana((at))gmx.de homepage: http://www.aldana-online.de -- View this message in context: http://www.nabble.com/performance-issue-of-built-in-container-tp15351794p15351794.html Sent from the archiva-users mailing list archive at Nabble.com.
Re: Maven Concepts
Hi, This is an excellent explanation, thanks for posting. How do executions fit into this? Is it that the pom can define many executions of a plugin, each with different configuration and phases (and potentially goals). How do you 'run' a single execution of a plugin, in a similar way to calling mvn plugin:goal to run a goal? Thanks for any explanations, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: surefire 2.4 + testng, changing "TestSuite" name
Thanks Dan, I have uploaded a fixed version of my patch, checking before casting to TestNGDirectoryTestSuite. With that fix, all unit tests and integration tests pass. I'm sorry I have missed this test failure earlier, should not happen... Erez. On Feb 8, 2008 4:14 AM, Dan Fabulich <[EMAIL PROTECTED]> wrote: > Erez Nahir wrote: > > > Created http://jira.codehaus.org/browse/SUREFIRE-452 and provided fix > for it > > as attachment. > > I saw your bug; it seems to fail some of the integration tests, so I'm not > applying it right now. > > > Can someone from surefire team clarify when is the next minor release of > > surefire-plugin planned? > > I don't think we have any schedules/plans, but you're in luck, because > there's a handful of bugs that we found right around the time that 2.4.1 > shipped. [Maybe people were waiting for the first service pack ;-)] > > If you can get me a patch that passes the tests in the next couple of > days, I'll probably submit it. > > -Dan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Archivia war link broken
forgot to mention, but fixed this yesterday :) On 07/02/2008, Stefano Fornari <[EMAIL PROTECTED]> wrote: > Hi, > I am not sure who I should point this out, but the link of the war > distribution of archivia is broken; it is: > > http://mirror.nohup.it/apache/maven/binaries/apache-archiva-1.0.1war > instead of > http://mirror.nohup.it/apache/maven/binaries/apache-archiva-1.0.1.war > > regards > Ste > > -- > Stefano Fornari - Funambol CTO > === > Home: > http://www.funambol.org > > Documents: > http://www.funambol.org/documentation/documents.html > > FAQ: > http://www.funambol.org/support/faq.html > > WIKI: > https://wiki.objectweb.org/sync4j/ > > Mailinglist archives: > http://groups.yahoo.com/group/Sync4j (login required) > http://sourceforge.net/mailarchive/forum.php?forum_id=215 (sync4j-users) > http://sourceforge.net/mailarchive/forum.php?forum_id=48877 > (funambol-dev) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
regression un maven 2.0.8
>From previous maven builds I used to override code-generator-plugin
dependencies to set the generator version :
example :
org.codehaus.mojo
axistools-maven-plugin
1.2-SNAPSHOT
axis
axis
${axis.version}
Using maven 2.0.8, this doesn't seem to work anymore.
I don't know how to dump the plugin classpath. mvn -X shows :
[DEBUG] Configuring mojo '
org.codehaus.mojo:axistools-maven-plugin:1.2-SNAPSHOT:wsdl2java' -->
[DEBUG] (f) pluginArtifacts = [axis:axis-ant:jar:1.1:compile,
axis:axis:jar:1.4:runtime, commons-logging:commons-logging:jar:1.0.4:runtime,
commons-discovery:commons-discovery:jar:0.2:runtime,
plexus:plexus-utils:jar:1.0.1:runtime, org.codehaus.plexus:plex
us-utils:jar:1.1:runtime, wsdl4j:wsdl4j:jar:1.5.2:compile,
org.codehaus.plexus:plexus-compiler-api:jar:1.5.1:runtime,
axis:axis:jar:1.1:runtime, org.apache.maven:maven-core:jar:2.0:runtime]
Please note there is 2 axis:axis:jar in the list !!
Nico.
