Re: User's project-specific properties ability disabled after MNG-4060
Well, the mixin support should cover the profiles.xml and moreeven better it should be possible to resolve the mixins from the repository which means they are versioned and deployed artifacts like everything else. On Wed, Jun 24, 2009 at 11:41 AM, Robert Scholte wrote: > > In the settings.xml it's not possible to activate a profile by project. > Then > again: I believe settings.xml are actually maven-settings and not > project-settings. For most users it's a big step to dive into the > settings.xml. For them there are only a few reasons to access the settings > file: > - to setup a proxy repository like nexus (which is often done by a more > experienced user) > - to set username+pw for a specific server. > If they don't have to touch the file then leave it, 'cause changes here > might break maven. > And a user-specific project-profile has to be located on a very logic and > easy to access location, so the best option is next to the pom I guess. > > -regards, > > Robert Scholte > > > > BRIAN FOX-5 wrote: > > > > Why not just put those values into the settings.xml? > > > > On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte > > wrote: > >> > >> I heard some time ago that the profiles.xml were removed in Maven3. > >> Although I'm still using 2.1.0 I want to be prepared for such changes. > >> > >> IMHO I think it's a bad choice to remove this option. > >> > >> > >> > >> Maven should provide some sort of way where developers can set/change > >> project properties without having to change the pom.xml. > >> > >> I believe the pom should not contain developer-specific properties and > >> which can or will end up in any scm. Think of datasource-properties. > >> > >> > >> > >> There are three degrees of properties: > >> > >> - the global properties (combined with the activeByDefault-profile) > >> > >> - profile-properties (where profiles cover multiple users. By OS, > >> 'stage') > >> > >> - personal properties. > >> > >> > >> > >> These personal properties can only be used with a personal profile. A > >> personal profile is the best example of data which doesn´t belong in a > >> pom but in a separate file (and probably not in scm). > >> > >> Personal properties should be somewhere close to the project, like in > the > >> root of the project (yes, like the profiles.xml). > >> > >> The both settings.xml is too far from the project and there's no option > >> in the (user's) settings.xml to set project-specific properties. > >> > >> > >> > >> I think that if there was a vote concerning this issue it might result > in > >> a long discussion. It's never too late for that, so let's give it a try. > >> > >> > >> > >> _ > >> Express yourself instantly with MSN Messenger! Download today it's FREE! > >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > -- > View this message in context: > http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: maven-eclipse-plugin failing on hudson - help needed.
>From inside an the antrun plugin? On Thu, Jun 25, 2009 at 1:42 AM, Brian Fox wrote: > use new File(basedir,) > > On Tue, Jun 23, 2009 at 4:21 PM, Barrie Treloar wrote: >> Interesting... >> >> [INFO] Executing tasks >> [echo] script = >> /home/hudson/workspace/plugins-CI-with-maven-2.1.x/jdk/1.5/label/ubuntu/trunk/maven-eclipse-plugin/verify-integration-tests-checks.bsh >> Jun 23, 2009 5:10:38 PM org.apache.bsf.BSFManager exec >> SEVERE: Exception : >> java.security.PrivilegedActionException: org.apache.bsf.BSFException: >> The application script threw an exception: >> java.io.FileNotFoundException: >> /home/hudson/workspace/plugins-CI-with-maven-2.1.x/jdk/1.5/label/ubuntu/trunk/maven-antrun.bsh >> (No such file or directory) BSF info: ANT at line: 0 column: columnNo >> >> So a relative file resolved via ant points to the correct location, >> yet the relative location resolved in the script points to the parent >> location. Wierd. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: User's project-specific properties ability disabled after MNG-4060
In the settings.xml it's not possible to activate a profile by project. Then again: I believe settings.xml are actually maven-settings and not project-settings. For most users it's a big step to dive into the settings.xml. For them there are only a few reasons to access the settings file: - to setup a proxy repository like nexus (which is often done by a more experienced user) - to set username+pw for a specific server. If they don't have to touch the file then leave it, 'cause changes here might break maven. And a user-specific project-profile has to be located on a very logic and easy to access location, so the best option is next to the pom I guess. -regards, Robert Scholte BRIAN FOX-5 wrote: > > Why not just put those values into the settings.xml? > > On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte > wrote: >> >> I heard some time ago that the profiles.xml were removed in Maven3. >> Although I'm still using 2.1.0 I want to be prepared for such changes. >> >> IMHO I think it's a bad choice to remove this option. >> >> >> >> Maven should provide some sort of way where developers can set/change >> project properties without having to change the pom.xml. >> >> I believe the pom should not contain developer-specific properties and >> which can or will end up in any scm. Think of datasource-properties. >> >> >> >> There are three degrees of properties: >> >> - the global properties (combined with the activeByDefault-profile) >> >> - profile-properties (where profiles cover multiple users. By OS, >> 'stage') >> >> - personal properties. >> >> >> >> These personal properties can only be used with a personal profile. A >> personal profile is the best example of data which doesn´t belong in a >> pom but in a separate file (and probably not in scm). >> >> Personal properties should be somewhere close to the project, like in the >> root of the project (yes, like the profiles.xml). >> >> The both settings.xml is too far from the project and there's no option >> in the (user's) settings.xml to set project-specific properties. >> >> >> >> I think that if there was a vote concerning this issue it might result in >> a long discussion. It's never too late for that, so let's give it a try. >> >> >> >> _ >> Express yourself instantly with MSN Messenger! Download today it's FREE! >> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > > -- View this message in context: http://www.nabble.com/User%27s-project-specific-properties-ability-disabled-after-MNG-4060-tp24183522p24190525.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Concurrent access to local repository by multiple processes
On Wed, Jun 24, 2009 at 10:07 AM, Jason Voegele wrote: > Thanks for the response. I guess I'll try my hand at using a lock file or > something similar in my wrapper scripts. I'm thinking that this algorithm > might work: You might look at Don Brown's work on parallel resolution of artifacts [1], which must have some kind of locking and is in 2.1.0. Perhaps that could be extended to work for other things that are accessing the repo. [1] http://jira.codehaus.org/browse/MNG-3379 -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Concurrent access to local repository by multiple processes
Brian Fox wrote: Almost certainly no. The 2.1 you saw mentioned most likely refers to the old 2.1 that is now 3.0. FWIW, I don't believe this has been or will be addressed in 3.0.0 which is focused on 2.x compatibility. http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/ Thanks for the response. I guess I'll try my hand at using a lock file or something similar in my wrapper scripts. I'm thinking that this algorithm might work: sleep_until_granted_lock mvn dependency:go-offline release_lock mvn --offline deploy Any thoughts on the above? -- Jason Voegele An investment in knowledge always pays the best interest. -- Benjamin Franklin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: User's project-specific properties ability disabled after MNG-4060
A major difference is that the settings.xml file is not stored with the project source. If your project depends on the profile(s) in some crucial way the information should be archived with the project. In that case the settings.xml is not an option. Stan - Original Message - From: Brian Fox To: Maven Developers List Sent: Wed Jun 24 12:22:33 2009 Subject: Re: User's project-specific properties ability disabled after MNG-4060 Why not just put those values into the settings.xml? On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte wrote: > > I heard some time ago that the profiles.xml were removed in Maven3. Although > I'm still using 2.1.0 I want to be prepared for such changes. > > IMHO I think it's a bad choice to remove this option. > > > > Maven should provide some sort of way where developers can set/change project > properties without having to change the pom.xml. > > I believe the pom should not contain developer-specific properties and which > can or will end up in any scm. Think of datasource-properties. > > > > There are three degrees of properties: > > - the global properties (combined with the activeByDefault-profile) > > - profile-properties (where profiles cover multiple users. By OS, 'stage') > > - personal properties. > > > > These personal properties can only be used with a personal profile. A > personal profile is the best example of data which doesn´t belong in a pom > but in a separate file (and probably not in scm). > > Personal properties should be somewhere close to the project, like in the > root of the project (yes, like the profiles.xml). > > The both settings.xml is too far from the project and there's no option in > the (user's) settings.xml to set project-specific properties. > > > > I think that if there was a vote concerning this issue it might result in a > long discussion. It's never too late for that, so let's give it a try. > > > > _ > Express yourself instantly with MSN Messenger! Download today it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: User's project-specific properties ability disabled after MNG-4060
Why not just put those values into the settings.xml? On Wed, Jun 24, 2009 at 4:31 AM, Robert Scholte wrote: > > I heard some time ago that the profiles.xml were removed in Maven3. Although > I'm still using 2.1.0 I want to be prepared for such changes. > > IMHO I think it's a bad choice to remove this option. > > > > Maven should provide some sort of way where developers can set/change project > properties without having to change the pom.xml. > > I believe the pom should not contain developer-specific properties and which > can or will end up in any scm. Think of datasource-properties. > > > > There are three degrees of properties: > > - the global properties (combined with the activeByDefault-profile) > > - profile-properties (where profiles cover multiple users. By OS, 'stage') > > - personal properties. > > > > These personal properties can only be used with a personal profile. A > personal profile is the best example of data which doesn´t belong in a pom > but in a separate file (and probably not in scm). > > Personal properties should be somewhere close to the project, like in the > root of the project (yes, like the profiles.xml). > > The both settings.xml is too far from the project and there's no option in > the (user's) settings.xml to set project-specific properties. > > > > I think that if there was a vote concerning this issue it might result in a > long discussion. It's never too late for that, so let's give it a try. > > > > _ > Express yourself instantly with MSN Messenger! Download today it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-eclipse-plugin failing on hudson - help needed.
use new File(basedir,) On Tue, Jun 23, 2009 at 4:21 PM, Barrie Treloar wrote: > Interesting... > > [INFO] Executing tasks > [echo] script = > /home/hudson/workspace/plugins-CI-with-maven-2.1.x/jdk/1.5/label/ubuntu/trunk/maven-eclipse-plugin/verify-integration-tests-checks.bsh > Jun 23, 2009 5:10:38 PM org.apache.bsf.BSFManager exec > SEVERE: Exception : > java.security.PrivilegedActionException: org.apache.bsf.BSFException: > The application script threw an exception: > java.io.FileNotFoundException: > /home/hudson/workspace/plugins-CI-with-maven-2.1.x/jdk/1.5/label/ubuntu/trunk/maven-antrun.bsh > (No such file or directory) BSF info: ANT at line: 0 column: columnNo > > So a relative file resolved via ant points to the correct location, > yet the relative location resolved in the script points to the parent > location. Wierd. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Concurrent access to local repository by multiple processes
Almost certainly no. The 2.1 you saw mentioned most likely refers to the old 2.1 that is now 3.0. FWIW, I don't believe this has been or will be addressed in 3.0.0 which is focused on 2.x compatibility. http://www.sonatype.com/people/2008/11/a-visual-history-of-maven-2/ On Wed, Jun 24, 2009 at 5:55 AM, Jason Voegele wrote: > I am wondering if it is now safe to have multiple Maven 2.1.0 processes > running concurrently using the same local repository. I know that with > older versions of Maven this was certainly not safe, but reading comments on > some JIRA issues leads me to believe that this may have been addressed with > Maven 2.1.0. Can anyone comment with any amount of certainty? > > -- > Jason Voegele > An investment in knowledge always pays the best interest. > -- Benjamin Franklin > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Doxia-1.1.1 and Doxia-Sitetools-1.1.1 Released
We are pleased to announce the release of Maven Doxia and Maven Doxia Sitetools,
version 1.1.1.
Doxia is a content generation framework that provides powerful techniques for
generating static and dynamic content: Doxia can be used in a web-based publishing
context to generate static sites, in addition to being incorporated into dynamic
content generation systems like blogs, wikis and content management systems.
http://maven.apache.org/doxia/
Release Notes - Maven Doxia - Version 1.1.1
Bug
* [DOXIA-118] - Image directory list field for PDF generation
* [DOXIA-129] - Allow correctly head element in xdoc
* [DOXIA-134] - Apt parser issues
* [DOXIA-184] - Docbook issues
* [DOXIA-232] - Confluence: Nested list parsing is not generating correct
events
* [DOXIA-239] - Handle non-ASCII characters in anchors and id's
* [DOXIA-281] - Add macro support in FML
* [DOXIA-294] - Apt verbatim box not correct
* [DOXIA-296] - HTML is escaped inside
* [DOXIA-299] - Confluence: Text formatting in sections does not work.
* [DOXIA-300] - Confluence: Bold markup on start of a document does not
work.
* [DOXIA-301] - Confluence: Invalid interpretation of links' aliases in
tables.
* [DOXIA-302] - Confluence: {code} tag is not interpreted correctly if there
is no empty line before it
* [DOXIA-304] - FO Sink does not recognize attributes of img tags
* [DOXIA-305] - FO: layout properties are not configurable
* [DOXIA-306] - FoAggregateSink doesn't resolve links to images in other
source folder
* [DOXIA-307] - Tests fail when run with Java 1.4
* [DOXIA-308] - encodeId returns an empty string which is not a valid id
* [DOXIA-309] - Ligature in author name shows up on page
* [DOXIA-310] - Unable to get custom entity references to work
* [DOXIA-311] - Character references do not work in xdoc section titles
* [DOXIA-312] - comments in meta properties end up in author content
* [DOXIA-314] - Custom entities do not work in xdoc section titles
* [DOXIA-316] - Backward issue: wrong section counting in TOC macro
* [DOXIA-318] - book descriptor element not properly translatetd for
latex output
* [DOXIA-321] - Image handling in docbook
* [DOXIA-323] - Apt parser garbles some special characters inside tables
* [DOXIA-324] - Doxia generates wrong xdoc when generating book from docbook
* [DOXIA-325] - Not valid xhtml document if comment with minus character
* [DOXIA-326] - Xhtml sink should preserve CDATA within
Concurrent access to local repository by multiple processes
I am wondering if it is now safe to have multiple Maven 2.1.0 processes running concurrently using the same local repository. I know that with older versions of Maven this was certainly not safe, but reading comments on some JIRA issues leads me to believe that this may have been addressed with Maven 2.1.0. Can anyone comment with any amount of certainty? -- Jason Voegele An investment in knowledge always pays the best interest. -- Benjamin Franklin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
User's project-specific properties ability disabled after MNG-4060
I heard some time ago that the profiles.xml were removed in Maven3. Although I'm still using 2.1.0 I want to be prepared for such changes. IMHO I think it's a bad choice to remove this option. Maven should provide some sort of way where developers can set/change project properties without having to change the pom.xml. I believe the pom should not contain developer-specific properties and which can or will end up in any scm. Think of datasource-properties. There are three degrees of properties: - the global properties (combined with the activeByDefault-profile) - profile-properties (where profiles cover multiple users. By OS, 'stage') - personal properties. These personal properties can only be used with a personal profile. A personal profile is the best example of data which doesn´t belong in a pom but in a separate file (and probably not in scm). Personal properties should be somewhere close to the project, like in the root of the project (yes, like the profiles.xml). The both settings.xml is too far from the project and there's no option in the (user's) settings.xml to set project-specific properties. I think that if there was a vote concerning this issue it might result in a long discussion. It's never too late for that, so let's give it a try. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[Result] [Vote] Release Doxia-1.1.1 and Doxia-Sitetools-1.1.1 (take two)
Ok, the signatures are fixed in the staging repo, thanks to Brian, so I'd say we call it a release. The voting period has passed and we have 3 binding +1 (Vincent, Benjamin, myself), plus one non-binding (Nicolas). I'll wait a few more hours before promoting the artifacts if anybody wants to re-check the signatures, but the vote is formally closed now. Thanks, -Lukas Lukas Theussl wrote: Hi again, We have cranked some more 23 issues into this release since the last failed attempt, so now we're at 47 (Doxia) and 6 (Sitetools) solved issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=15073 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11624&styleName=Html&version=15075 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10780&status=1 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11624&status=1 Staging repos: https://repository.apache.org/content/repositories/maven-staging-019/ https://repository.apache.org/content/repositories/maven-staging-020/ Staging sites: http://maven.apache.org/doxia/doxia/ http://maven.apache.org/doxia/doxia-sitetools/ (I have deployed to the main sites as nothing major has changed wrt 1.1 and I can't use site:stage because of MSITE-404) Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Note: the most convenient way to test (I think) is to use site-plugin-2.1-SNAPSHOT and/or pdf-plugin-1.0-SNAPSHOT, which both use the latest doxia snaps. Vote is open for 72 hours. [x] +1 [ ] +0 [ ] -1 Thanks, -Lukas - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
