Re: [VOTE] Release compiler plugin 2.0.2
Result: +1: 3 Now that the parents are released i'll proceed with the release On 1/17/07, Rahul Thakur <[EMAIL PROTECTED]> wrote: +1 Rahul Jesse McConnell wrote: > +1 > > On 1/17/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: >> +1 >> >> - Joakim >> >> Carlos Sanchez wrote: >> > It fixes a couple of annoying issues for windows users >> > >> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11130&fixfor=12484 >> >> > >> > >> > One question, can the 2.0.x branch no longer needed be deleted to >> > avoid confusion? >> > >> https://svn.apache.org/repos/asf/maven/plugins/branches/maven-compiler-plugin-2.0.x >> >> > >> > >> >> >> - >> 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] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506758 - /maven/KEYS
Hi Carlos, According Jason [1], the /maven/KEYS is not used anymore. Cheers, Vincent [1] http://www.nabble.com/Keys-question-tf2949415s177.html#a8248427 2007/2/12, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Author: carlos Date: Mon Feb 12 16:08:51 2007 New Revision: 506758 URL: http://svn.apache.org/viewvc?view=rev&rev=506758 Log: Add my PGP key Modified: maven/KEYS Modified: maven/KEYS URL: http://svn.apache.org/viewvc/maven/KEYS?view=diff&rev=506758&r1=506757&r2=506758 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Release Maven 2.0.5 (take 2)
Hi Fabrice,
I'm doing exactly what you describe and from what I can see, the latest
2.0.5 is working ok. I did find an issue in one of the early 2.0.5
release candidates, but it was fixed. The method I use is attached to
http://jira.codehaus.org/browse/MNG-2749.
Thanks,
Brian
-Original Message-
From: Fabrice Bellingard [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 10:02 AM
To: Maven Developers List
Subject: Re: [VOTE] Release Maven 2.0.5 (take 2)
Hi Jason,
The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader problem
loading a resource from a build extension Jar") still breaks my
integrations
with this last build of Maven... :-( As you tried the test project
successfully, I don't understand what can be specific to my environment
.
I've made a clean installation of Maven (no local repository and last
build
of 2.0.5), and still it breaks the test case I attached on JIRA.
Is there someone here who develops Checkstyle custom Checks and bundles
them
in a JAR (along with the configuration file) which is specified in the
build
extensions of another project? Or at least someone else who could test
the
case I described on JIRA? (with a clean installation)
I may sound insisting on this, but the fact is that we have developed
custom
Checks in my company, and tens of projects are using them to generate
the
checkstyle report. As 2.0.5 currently breaks our builds, they wouldn't
be
able to migrate to this new and awaited version of Maven. Which is sad
because they're looking forward to using it...
Apart from that, everything works fine. :-)
Fabrice.
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> The assemblies that people are interested in are staged here:
>
>
http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/
> maven-core/2.0.5/
>
> Here is the JIRA roadmap:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa ?
> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> order=DESC
>
> +1
>
> Thanks,
>
> Jason.
>
>
> -
> 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: Cannot Buily Archiva Trunk
Fixed. On 13/02/2007, at 10:31 AM, Robert Simmons jr. Simmons wrote: When I try to build the trunk of archiva I get the following error: [INFO] snapshot org.codehaus.modello:modello:1.0-alpha-14- SNAPSHOT: checking for updates from apache.snapshots Downloading: http://snapshots.repository.codehaus.org/org/codehaus/modello/ modello/ 1.0-alpha-14-SNAPSHOT/modello-1.0-alpha-14-20070209.133120-3.pom 10K downloaded [INFO] - --- [ERROR] BUILD FAILURE [INFO] - --- [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.codehaus.modello -DartifactId=modello-maven-plugin \ -Dversion=1.0-alpha-14-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file org.codehaus.modello:modello-maven-plugin:maven-plugin:1.0- alpha-14-SNAPSHOT This seems strange since it looks like the plugin is downloaded properly and installed properly. However, If I download that plugin and install it manually into my Maven repo then I get an error: [ERROR] BUILD ERROR [INFO] - --- [INFO] 'registry-reader' was specified in an execution, but not found in the plugin Commenting out the line in the pom.xml will result in registry-writer throwing an exception and commenting both out results in unfound symbol errors during compile. Basicallt neither the trunk nor the MRM-239 branches build. Robert Simmons jr. Senior Software Engineer ICAT Managers, LLC 720-271-9343 [EMAIL PROTECTED] Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.
RE: [VOTE] Release Maven 2.0.5 (take 2)
"Well, in any case it would be great to integrate the code of http://jira.codehaus.org/browse/MNG-2676 into the dependencies plugin and get a release. It is a great help to analyse and fix such situations (here integrated into our internal info plugin)" The current alpha-2 release is close to ready with just a couple of issues. Anything major like this I'd like to put into alpha-3 so it doesn't hold up the release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cannot Buily Archiva Trunk
When I try to build the trunk of archiva I get the following error: > [INFO] snapshot org.codehaus.modello:modello:1.0-alpha-14-SNAPSHOT: checking > for updates from apache.snapshots > Downloading: > http://snapshots.repository.codehaus.org/org/codehaus/modello/modello/ > 1.0-alpha-14-SNAPSHOT/modello-1.0-alpha-14-20070209.133120-3.pom > 10K downloaded > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] A required plugin was not found: Plugin could not be found - check that > the goal name is correct: Unable to download the artifact from any repository > > Try downloading the file manually from the project website. > > Then, install it using the command: > mvn install:install-file -DgroupId=org.codehaus.modello > -DartifactId=modello-maven-plugin \ > -Dversion=1.0-alpha-14-SNAPSHOT -Dpackaging=maven-plugin > -Dfile=/path/to/file > > org.codehaus.modello:modello-maven-plugin:maven-plugin:1.0-alpha-14-SNAPSHOT This seems strange since it looks like the plugin is downloaded properly and installed properly. However, If I download that plugin and install it manually into my Maven repo then I get an error: > [ERROR] BUILD ERROR > [INFO] > > [INFO] 'registry-reader' was specified in an execution, but not found in the > plugin Commenting out the line in the pom.xml will result in registry-writer throwing an exception and commenting both out results in unfound symbol errors during compile. Basicallt neither the trunk nor the MRM-239 branches build. Robert Simmons jr. Senior Software Engineer ICAT Managers, LLC 720-271-9343 [EMAIL PROTECTED] Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.
Re: exit code on windows
http://jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&mode=hide&pid=10500&sorter/order=DESC&sorter/
field=priority&resolution=-1&component=11982
On 12 Feb 07, at 5:11 PM 12 Feb 07, Tomasz Pik wrote:
Hello,
After running some tests I've found that on Windows
maven-invoker-plugin is not handling errors correctly.
POMs for invoked projects may be broken and m-i-p
still reports them as success.
There's a couple of resolved issues in MNG JIRA
related to exit error code on windows and currently
mvn.bat contains
if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE%
which means, that if mvn.bat will be invoked with
MAVEN_TERMINATE_CMD environment variable
set to 'on', then script will return non-zero code
if build will fail. Which is exactly as expected...
.. as long, as script is being invoked with this variable
being set.
But mvn.bat invoked from DefaultInvoker is invoked
without any changes in environment so without this
variable being set by default.
Using 'exit %ERROR_CODE%' means also, that 'cmd'
running maven will also be closed so it's not too practical
for windows users to set this value - they needs to open
new window every time so it's not a good idea to set
MAVEN_TERMINATE_CMD=on as global value.
So - to make all of this working as expected (to make
maven-invoker-plugin reports failed tests as failures)
cli.addEnvironment("MAVEN_TERMINATE_CMD", "on");
needs to be added to DefaultInvoker.
Where in JIRA I should added this as an issue?
Regards,
Tomek
PS I've also found a more practical workaround :)
remove /B in last line of mvn.bat and use cygwin to
run 'mvn' shell script. So main maven execution is
controlled by cygwin and child executions are controlled
by mvn.bat, which returns error code as expected.
Probably mvn.bat may set up this variable before executing
java so child executions will return exit codes and main script
(the same script, main execution in fact) will use global value?
WDYT?
-
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: Invalid link on Maven site
Jorg, Thanks for the report. I've fixed the site sources in svn. I'd appreciate it if someone could deploy the site. My site-plugin and doxia setup is too many versions into the future right now. -- Dennis Lundberg Jorg Heymans wrote: Related: The page http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html looks messed up. In fact most of the pages for that plugin seem to suffer from the same problem Jorg Julien HENRY wrote: Hi, On this page : http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html The link : Check out the Guide to Configuring Maven if necessary. is invalid. ++ Julien ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
+1 -- Dennis Lundberg Stephane Nicoll wrote: Hi, This release fixes all known issues. Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Revision: 505872 The staging bits are available as well: http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ Vote opens for 72hours. My +1 Thanks, Stéphane - 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: [VOTE] Release Maven 2.0.5 (take 2)
Actually, using build extensions in ways that worked in Maven 2.0.4 now fail in 2.0.5 for me using Fedora Core 6. - Stephen On 2/12/07, Fabrice Bellingard <[EMAIL PROTECTED]> wrote: Thanks for the hint, Dan, this actually works perfectly! I wasn't aware of this way to specify the JAR. It would be worth updating the documentation of the Checkstyle plugin. I will create a JIRA issue for this. FYI, Jason, yes, I've executed the test project on the bane of your existence ;-) - Windows XP with Java 1.5.0_06 - Windows 2k with Java 1.4.2_02 So even if this way of using the build extension is deprecated, I think this remains a bug on Windows. Anyways, everything works fine now. So here is my (non-binding) +1 :-) Fabrice. On 2/12/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Just FYI: we (CXF team) put our checkstyle rules into a jar bundle and use > that. However, we don't put it in the extensions. We put it as a > direct > dependency for the plugin: > > org.apache.maven.plugins > maven-checkstyle-plugin > > > org.apache.cxf > cxf-buildtools > . > > > .. > > and that works fine with 2.0.5. > > > Dan > -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
Thanks for the hint, Dan, this actually works perfectly! I wasn't aware of this way to specify the JAR. It would be worth updating the documentation of the Checkstyle plugin. I will create a JIRA issue for this. FYI, Jason, yes, I've executed the test project on the bane of your existence ;-) - Windows XP with Java 1.5.0_06 - Windows 2k with Java 1.4.2_02 So even if this way of using the build extension is deprecated, I think this remains a bug on Windows. Anyways, everything works fine now. So here is my (non-binding) +1 :-) Fabrice. On 2/12/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: Just FYI: we (CXF team) put our checkstyle rules into a jar bundle and use that. However, we don't put it in the extensions. We put it as a direct dependency for the plugin: org.apache.maven.plugins maven-checkstyle-plugin org.apache.cxf cxf-buildtools . .. and that works fine with 2.0.5. Dan
Re: [VOTE] Release Maven 2.0.5 (take 2)
Aha! Apparently this was fixed in Maven 2.0.5, as I just tested and
it failed with 2.0.4, but worked when I tried it right afterward in
2.0.5.
Similarly, I have a project that uses the xfire-generator wsgen task,
and I had it defined as an extension. This works with 2.0.4, but is
broken with 2.0.5. However, changing it to a plugin dependency made
it work again.
Beyond this issue of extensions vs. plugin dependencies, the rest of
my build worked fine with Maven 2.0.5.
-Stephen
On 2/12/07, Stephen Duncan <[EMAIL PROTECTED]> wrote:
I've actually been telling people on the mailing list to use
extensions for jar with checkstyle configuration, rather than
plugin->dependencies. The reason was that, in my testing at the time,
if you didn't already have that plugin dependency in your local repo,
it would not search for it in all your defined repos, it would only
look in central, and therefore break for other people. At the time I
just assumed using extensions was the right mechanism, but if
plugin->dependencies is 'correct' then it should be verified that it
works correctly...
-Stephen
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> What Dan describes is probably more correct and we should document
> this because extensions are really something that executes where you
> really just want something on the classpath of the plugin. But as far
> as I can tell with the test that I checked in the extension works,
> but that should really be a deprecated form of use.
>
> jason.
>
> On 12 Feb 07, at 10:17 AM 12 Feb 07, Daniel Kulp wrote:
>
> >
> > Fabrice,
> >
> > On Monday 12 February 2007 10:02, Fabrice Bellingard wrote:
> >> The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader
> >> problem
> >> loading a resource from a build extension Jar") still breaks my
> >> integrations with this last build of Maven... :-( As you tried the
> >> test
> >> project successfully, I don't understand what can be specific to my
> >> environment . I've made a clean installation of Maven (no local
> >> repository
> >> and last build of 2.0.5), and still it breaks the test case I
> >> attached on
> >> JIRA.
> >>
> >> Is there someone here who develops Checkstyle custom Checks and
> >> bundles
> >> them in a JAR (along with the configuration file) which is
> >> specified in the
> >> build extensions of another project? Or at least someone else who
> >> could
> >> test the case I described on JIRA? (with a clean installation)
> >
> > Just FYI: we (CXF team) put our checkstyle rules into a jar bundle
> > and use
> > that. However, we don't put it in the extensions. We put it as
> > a direct
> > dependency for the plugin:
> >
> > org.apache.maven.plugins
> > maven-checkstyle-plugin
> >
> >
> > org.apache.cxf
> > cxf-buildtools
> > .
> >
> >
> > ..
> >
> > and that works fine with 2.0.5.
> >
> >
> > Dan
> >
> >
> >
> >>
> >> I may sound insisting on this, but the fact is that we have developed
> >> custom Checks in my company, and tens of projects are using them to
> >> generate the checkstyle report. As 2.0.5 currently breaks our
> >> builds, they
> >> wouldn't be able to migrate to this new and awaited version of
> >> Maven. Which
> >> is sad because they're looking forward to using it...
> >>
> >> Apart from that, everything works fine. :-)
> >>
> >> Fabrice.
> >>
> >> On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> >>> Hi,
> >>>
> >>> The assemblies that people are interested in are staged here:
> >>>
> >>> http://people.apache.org/~jvanzyl/staging-repository/org/apache/
> >>> maven/ >>> tp://people.apache.org/%7Ejvanzyl/staging-repository/org/apache/
> >>> maven/>
> >>> maven-core/2.0.5/
> >>>
> >>> Here is the JIRA roadmap:
> >>>
> >>> http://jira.codehaus.org/secure/IssueNavigator.jspa ?
> >>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> >>> order=DESC
> >>>
> >>> +1
> >>>
> >>> Thanks,
> >>>
> >>> Jason.
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727C: 508-380-7194
> > [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]
>
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
--
Stephen Duncan Jr
www.stephenduncanjr.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 Rahul Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC +1 Thanks, Jason. - 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: [VOTE] Release Maven 2.0.5 (take 2)
I've actually been telling people on the mailing list to use
extensions for jar with checkstyle configuration, rather than
plugin->dependencies. The reason was that, in my testing at the time,
if you didn't already have that plugin dependency in your local repo,
it would not search for it in all your defined repos, it would only
look in central, and therefore break for other people. At the time I
just assumed using extensions was the right mechanism, but if
plugin->dependencies is 'correct' then it should be verified that it
works correctly...
-Stephen
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
What Dan describes is probably more correct and we should document
this because extensions are really something that executes where you
really just want something on the classpath of the plugin. But as far
as I can tell with the test that I checked in the extension works,
but that should really be a deprecated form of use.
jason.
On 12 Feb 07, at 10:17 AM 12 Feb 07, Daniel Kulp wrote:
>
> Fabrice,
>
> On Monday 12 February 2007 10:02, Fabrice Bellingard wrote:
>> The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader
>> problem
>> loading a resource from a build extension Jar") still breaks my
>> integrations with this last build of Maven... :-( As you tried the
>> test
>> project successfully, I don't understand what can be specific to my
>> environment . I've made a clean installation of Maven (no local
>> repository
>> and last build of 2.0.5), and still it breaks the test case I
>> attached on
>> JIRA.
>>
>> Is there someone here who develops Checkstyle custom Checks and
>> bundles
>> them in a JAR (along with the configuration file) which is
>> specified in the
>> build extensions of another project? Or at least someone else who
>> could
>> test the case I described on JIRA? (with a clean installation)
>
> Just FYI: we (CXF team) put our checkstyle rules into a jar bundle
> and use
> that. However, we don't put it in the extensions. We put it as
> a direct
> dependency for the plugin:
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
> org.apache.cxf
> cxf-buildtools
> .
>
>
> ..
>
> and that works fine with 2.0.5.
>
>
> Dan
>
>
>
>>
>> I may sound insisting on this, but the fact is that we have developed
>> custom Checks in my company, and tens of projects are using them to
>> generate the checkstyle report. As 2.0.5 currently breaks our
>> builds, they
>> wouldn't be able to migrate to this new and awaited version of
>> Maven. Which
>> is sad because they're looking forward to using it...
>>
>> Apart from that, everything works fine. :-)
>>
>> Fabrice.
>>
>> On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> The assemblies that people are interested in are staged here:
>>>
>>> http://people.apache.org/~jvanzyl/staging-repository/org/apache/
>>> maven/>> tp://people.apache.org/%7Ejvanzyl/staging-repository/org/apache/
>>> maven/>
>>> maven-core/2.0.5/
>>>
>>> Here is the JIRA roadmap:
>>>
>>> http://jira.codehaus.org/secure/IssueNavigator.jspa ?
>>> reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
>>> order=DESC
>>>
>>> +1
>>>
>>> Thanks,
>>>
>>> Jason.
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727C: 508-380-7194
> [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]
--
Stephen Duncan Jr
www.stephenduncanjr.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
exit code on windows
Hello,
After running some tests I've found that on Windows
maven-invoker-plugin is not handling errors correctly.
POMs for invoked projects may be broken and m-i-p
still reports them as success.
There's a couple of resolved issues in MNG JIRA
related to exit error code on windows and currently
mvn.bat contains
if "%MAVEN_TERMINATE_CMD%" == "on" exit %ERROR_CODE%
which means, that if mvn.bat will be invoked with
MAVEN_TERMINATE_CMD environment variable
set to 'on', then script will return non-zero code
if build will fail. Which is exactly as expected...
.. as long, as script is being invoked with this variable
being set.
But mvn.bat invoked from DefaultInvoker is invoked
without any changes in environment so without this
variable being set by default.
Using 'exit %ERROR_CODE%' means also, that 'cmd'
running maven will also be closed so it's not too practical
for windows users to set this value - they needs to open
new window every time so it's not a good idea to set
MAVEN_TERMINATE_CMD=on as global value.
So - to make all of this working as expected (to make
maven-invoker-plugin reports failed tests as failures)
cli.addEnvironment("MAVEN_TERMINATE_CMD", "on");
needs to be added to DefaultInvoker.
Where in JIRA I should added this as an issue?
Regards,
Tomek
PS I've also found a more practical workaround :)
remove /B in last line of mvn.bat and use cygwin to
run 'mvn' shell script. So main maven execution is
controlled by cygwin and child executions are controlled
by mvn.bat, which returns error code as expected.
Probably mvn.bat may set up this variable before executing
java so child executions will return exit codes and main script
(the same script, main execution in fact) will use global value?
WDYT?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalid link on Maven site
Julien HENRY wrote: Hi, On this page : http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html The link : Check out the Guide to Configuring Maven if necessary. is invalid. ++ Julien Thanks for reporting this. It has, however, been solved in SVN already, see MNG-2801. The site just needs to be republished. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
On 12 Feb 07, at 4:06 PM 12 Feb 07, Jorg Heymans wrote: Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/ maven/maven-core/2.0.5/ Excalibur builds fine with this release, no apparent probs spotted. Cool, thanks for checking. Jason. Thanks, Jorg - 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: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Excalibur builds fine with this release, no apparent probs spotted. Thanks, Jorg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Escaping HTML entities for canoo webtests -- resources-plugin?
Do you think of a chain of filters like in ant?
But I wouldn't put this into the resources plugin, as this is a more
general idea and the resources plugin only filters *.properties files
(on ${...}... all files on @...@).
Am 12.02.2007 um 20:51 schrieb Aaron Digulla:
Mika Göckel wrote:
Hi!
My problem is, that I need to escape HTML entities in resource files
when coping them to target/test-classes.
Is it a good idea to extend resources-plugin to support something
like
escapeHtml=true as attribute or is it a better idea to create a
completely new mojo?
The best solution would be to allow chainable filter "plugins" in the
resource mojo :-) There are just so many way in which you can copy a
file. But I guess that's asking too much.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mika Göckel
[EMAIL PROTECTED]
Königswinterer Str. 374
53227 Bonn
tel 49 228 22 7776 11
fax 49 228 22 7776 29
skype mika.goeckel
skypeIn +492213008290
sip +49221355338812
mob +491722792771
Cybercon Gesellschaft für neue Medien mbH
Firmensitz: Rathausallee 10, 53737 Sankt Augustin
Registergericht: Amtsgericht Siegburg, HRB 4695
Geschäftsführer: Oliver Runge, Michael Göckel
Umsatzsteuer-ID: DE178714321
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 Emmanuel Jason van Zyl a écrit : Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC +1 Thanks, Jason. - 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-remote-resources-plugin (and apache-jar-resource-bundle) discussion...
On 12 Feb 07, at 2:49 PM 12 Feb 07, Daniel Kulp wrote: On my sandbox branch, I now have all the logged issues with the maven-remote-resources-plugin and the related apache-jar-resource- bundle now fixed. (List shown below) (All but one logged by me. :-) ) Since all known issues are fixed (once Jason merges my sandbox), should we start a release?Are the other issues in the backs of peoples minds that aren't logged yet that should be considered? If not, will someone volunteer to do the release (I cannot since I don't have commit access to do the tagging and such). Next question: do these changes make it useful enough to rev from 1.0-alpha-1 to a beta state, or leave as alpha-2? Once you go through two alphas without changing the configuration (really part of the api of the plugin) then I say it's safe to bump up to beta. I've deployed new snapshots: http://people.apache.org/repo/m2-snapshot-repository/org/apache/ apache-jar-resource-bundle/1.1-SNAPSHOT/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ maven/plugins/maven-remote-resources-plugin/1.0-alpha-2-SNAPSHOT/ for people to try out. Anyway, I have a couple projects that would like to depend on some of this. Thus, the sooner we get a release, the better.:-) I can do a merge today and call a vote tomorrow. Everyone will use it and complain once we release it. Jason. Thanks! Dan ** Bug * [MRRESOURCES-1] - Index for resourceBundle error messages is wrong * [MRRESOURCES-3] - Plugin does not populate the projects needed for the notices file * [MRRESOURCES-4] - If not resourceBundles specified (or element miss-spelled) you get a NullPointerException * [MRRESOURCES-5] - Uses hardcodes src/main/resources for location of overriding resources * [MRRESOURCES-6] - Remote resources are not added to test jars * [MRRESOURCES-7] - Multiple entries are ignored * [MRRESOURCES-10] - Generated eclipse projects complain about duplicated resources ** New Feature * [MRRESOURCES-2] - Support an "append" mode for local resources * [MRRESOURCES-8] - Should be able to pass additional properties into velocity * [MRRESOURCES-9] - For apache-jar-resource-bundle, would be nice to optionally have license information in the NOTICE -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [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: Escaping HTML entities for canoo webtests -- resources-plugin?
Mika Göckel wrote: > Hi! > > My problem is, that I need to escape HTML entities in resource files > when coping them to target/test-classes. > Is it a good idea to extend resources-plugin to support something like > escapeHtml=true as attribute or is it a better idea to create a > completely new mojo? The best solution would be to allow chainable filter "plugins" in the resource mojo :-) There are just so many way in which you can copy a file. But I guess that's asking too much. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-remote-resources-plugin (and apache-jar-resource-bundle) discussion...
On my sandbox branch, I now have all the logged issues with the maven-remote-resources-plugin and the related apache-jar-resource-bundle now fixed. (List shown below) (All but one logged by me. :-) ) Since all known issues are fixed (once Jason merges my sandbox), should we start a release?Are the other issues in the backs of peoples minds that aren't logged yet that should be considered? If not, will someone volunteer to do the release (I cannot since I don't have commit access to do the tagging and such). Next question: do these changes make it useful enough to rev from 1.0-alpha-1 to a beta state, or leave as alpha-2? I've deployed new snapshots: http://people.apache.org/repo/m2-snapshot-repository/org/apache/apache-jar-resource-bundle/1.1-SNAPSHOT/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-remote-resources-plugin/1.0-alpha-2-SNAPSHOT/ for people to try out. Anyway, I have a couple projects that would like to depend on some of this. Thus, the sooner we get a release, the better.:-) Thanks! Dan ** Bug * [MRRESOURCES-1] - Index for resourceBundle error messages is wrong * [MRRESOURCES-3] - Plugin does not populate the projects needed for the notices file * [MRRESOURCES-4] - If not resourceBundles specified (or element miss-spelled) you get a NullPointerException * [MRRESOURCES-5] - Uses hardcodes src/main/resources for location of overriding resources * [MRRESOURCES-6] - Remote resources are not added to test jars * [MRRESOURCES-7] - Multiple entries are ignored * [MRRESOURCES-10] - Generated eclipse projects complain about duplicated resources ** New Feature * [MRRESOURCES-2] - Support an "append" mode for local resources * [MRRESOURCES-8] - Should be able to pass additional properties into velocity * [MRRESOURCES-9] - For apache-jar-resource-bundle, would be nice to optionally have license information in the NOTICE -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
Stephane Nicoll wrote: > This release fixes all known issues. > ** Improvement >* [MSOURCES-11] - When source plugin is used, it should make sure > it is invoked during install YAY! +1 :-) Just to be sure: You checked with a parent POM? (ie. when the source plugin is configured in the *parent* POM and you run "install" in the module?) Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://www.pdark.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
+1 - Joakim Jason van Zyl wrote: > +1 > > Thanks Stephane, > > Jason. > > On 11 Feb 07, at 5:11 AM 11 Feb 07, Stephane Nicoll wrote: > >> Hi, >> >> This release fixes all known issues. >> >> Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 >> >> ** Bug >>* [MSOURCES-6] - Sources plugin ignores resource includes/excludes >> >> ** Improvement >>* [MSOURCES-11] - When source plugin is used, it should make sure >> it is invoked during install >> >> Revision: 505872 >> >> The staging bits are available as well: >> http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ >> >> >> Vote opens for 72hours. >> >> My +1 >> >> Thanks, >> >> Stéphane >> >> - >> 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]
Escaping HTML entities for canoo webtests -- resources-plugin?
Hi! My problem is, that I need to escape HTML entities in resource files when coping them to target/test-classes. Is it a good idea to extend resources-plugin to support something like escapeHtml=true as attribute or is it a better idea to create a completely new mojo? (Hit me if someone already has solved this problem :-) Cheers, Mika -- Mika Göckel [EMAIL PROTECTED] Königswinterer Str. 374 53227 Bonn tel 49 228 22 7776 11 fax 49 228 22 7776 29 skype mika.goeckel skypeIn +492213008290 sip +49221355338812 mob +491722792771 Cybercon Gesellschaft für neue Medien mbH Firmensitz: Rathausallee 10, 53737 Sankt Augustin Registergericht: Amtsgericht Siegburg, HRB 4695 Geschäftsführer: Oliver Runge, Michael Göckel Umsatzsteuer-ID: DE178714321
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 (looking forward to it) - Joakim Jason van Zyl wrote: > Hi, > > The assemblies that people are interested in are staged here: > > http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ > > > Here is the JIRA roadmap: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC > > > +1 > > Thanks, > > Jason. > > > - > 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: [VOTE] Release Maven 2.0.5 (take 2)
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/ maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/ order=DESC Error code from mvn.bat is not returned correctly on windows, solution described at continuum site is not working so maven-invoker-plugin cannot be treat as reliable tool. Steps to reproduce: * checkout maven-antrun-plugin * break one pom.xml files inside src/it/test_n directories * run mvn install at project level maven-invoker-plugin will report all tests as 'passed' but 'build.log' file in directory with broken pom will contain errors. Should I add it into JIRA? Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 from me. On 2/12/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: +1 (non-binding) Works for our builds. Thanks! Dan On Sunday 11 February 2007 23:33, Jason van Zyl wrote: > Hi, > > The assemblies that people are interested in are staged here: > > http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/ > maven-core/2.0.5/ > > Here is the JIRA roadmap: > > http://jira.codehaus.org/secure/IssueNavigator.jspa? > reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/ > order=DESC > > +1 > > Thanks, > > Jason. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506526 - /maven/sandbox/plugins/maven-remote-resources-plugin/README.txt
On Monday 12 February 2007 13:12, Jason van Zyl wrote: > If you want to track changes use the changes.xml format and the > changes plugin and we'll actually publish that with the release. I'm not using it to really track changes. That's what JIRA is for. I'm using it to track what stuff is on the branch/sandbox that hasn't yet been merged to trunk.Basically, when you (or someone) merges the changes to trunk, I need to know what JIRA numbers I need to go and resolve as fixed. (I don't consider a fix on a branch as "resolved" until it's committed to trunk.) Dan > Jason. > > On 12 Feb 07, at 11:36 AM 12 Feb 07, [EMAIL PROTECTED] wrote: > > Author: dkulp > > Date: Mon Feb 12 08:36:06 2007 > > New Revision: 506526 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=506526 > > Log: > > Add readme to describe changes > > > > Added: > > maven/sandbox/plugins/maven-remote-resources-plugin/ > > README.txt (with props) > > > > Added: maven/sandbox/plugins/maven-remote-resources-plugin/README.txt > > URL: http://svn.apache.org/viewvc/maven/sandbox/plugins/maven- > > remote-resources-plugin/README.txt?view=auto&rev=506526 > > == > > > > --- maven/sandbox/plugins/maven-remote-resources-plugin/README.txt > > (added) > > +++ maven/sandbox/plugins/maven-remote-resources-plugin/README.txt > > Mon Feb 12 08:36:06 2007 > > @@ -0,0 +1,11 @@ > > +Sandbox work on maven-remote-resources-plugin. > > + > > +Currently contains fixes for: (dkulp fixed on 2/12/07) > > +MRRESOURCES-8 - Add "properties" map to allow additional > > properties to be sent to velocity. > > +Documented the auto-added properties. > > +MRRESOURCES-9 - In https://svn.apache.org/repos/asf/maven/sandbox/ > > resources/apache-jar-resource-bundle > > +The template takes an "addLicense" property > > (requires MRRESOURCES-8) to add license > > + information for each dependency > > +MRRESOURCES-10 - exclude the original override files so generated > > projects don't complain > > + > > + > > > > Propchange: maven/sandbox/plugins/maven-remote-resources-plugin/ > > README.txt > > -- > > > > svn:eol-style = native > > > > Propchange: maven/sandbox/plugins/maven-remote-resources-plugin/ > > README.txt > > -- > > > > svn:mime-type = text/plain > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506526 - /maven/sandbox/plugins/maven-remote-resources-plugin/README.txt
If you want to track changes use the changes.xml format and the changes plugin and we'll actually publish that with the release. Jason. On 12 Feb 07, at 11:36 AM 12 Feb 07, [EMAIL PROTECTED] wrote: Author: dkulp Date: Mon Feb 12 08:36:06 2007 New Revision: 506526 URL: http://svn.apache.org/viewvc?view=rev&rev=506526 Log: Add readme to describe changes Added: maven/sandbox/plugins/maven-remote-resources-plugin/ README.txt (with props) Added: maven/sandbox/plugins/maven-remote-resources-plugin/README.txt URL: http://svn.apache.org/viewvc/maven/sandbox/plugins/maven- remote-resources-plugin/README.txt?view=auto&rev=506526 == --- maven/sandbox/plugins/maven-remote-resources-plugin/README.txt (added) +++ maven/sandbox/plugins/maven-remote-resources-plugin/README.txt Mon Feb 12 08:36:06 2007 @@ -0,0 +1,11 @@ +Sandbox work on maven-remote-resources-plugin. + +Currently contains fixes for: (dkulp fixed on 2/12/07) +MRRESOURCES-8 - Add "properties" map to allow additional properties to be sent to velocity. +Documented the auto-added properties. +MRRESOURCES-9 - In https://svn.apache.org/repos/asf/maven/sandbox/ resources/apache-jar-resource-bundle +The template takes an "addLicense" property (requires MRRESOURCES-8) to add license + information for each dependency +MRRESOURCES-10 - exclude the original override files so generated projects don't complain + + Propchange: maven/sandbox/plugins/maven-remote-resources-plugin/ README.txt -- svn:eol-style = native Propchange: maven/sandbox/plugins/maven-remote-resources-plugin/ README.txt -- svn:mime-type = text/plain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Invalid link on Maven site
Related: The page http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html looks messed up. In fact most of the pages for that plugin seem to suffer from the same problem Jorg Julien HENRY wrote: Hi, On this page : http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html The link : Check out the Guide to Configuring Maven if necessary. is invalid. ++ Julien ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 (non-binding) Works for our builds. Thanks! Dan On Sunday 11 February 2007 23:33, Jason van Zyl wrote: > Hi, > > The assemblies that people are interested in are staged here: > > http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/ > maven-core/2.0.5/ > > Here is the JIRA roadmap: > > http://jira.codehaus.org/secure/IssueNavigator.jspa? > reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/ > order=DESC > > +1 > > Thanks, > > Jason. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
What Dan describes is probably more correct and we should document
this because extensions are really something that executes where you
really just want something on the classpath of the plugin. But as far
as I can tell with the test that I checked in the extension works,
but that should really be a deprecated form of use.
jason.
On 12 Feb 07, at 10:17 AM 12 Feb 07, Daniel Kulp wrote:
Fabrice,
On Monday 12 February 2007 10:02, Fabrice Bellingard wrote:
The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader
problem
loading a resource from a build extension Jar") still breaks my
integrations with this last build of Maven... :-( As you tried the
test
project successfully, I don't understand what can be specific to my
environment . I've made a clean installation of Maven (no local
repository
and last build of 2.0.5), and still it breaks the test case I
attached on
JIRA.
Is there someone here who develops Checkstyle custom Checks and
bundles
them in a JAR (along with the configuration file) which is
specified in the
build extensions of another project? Or at least someone else who
could
test the case I described on JIRA? (with a clean installation)
Just FYI: we (CXF team) put our checkstyle rules into a jar bundle
and use
that. However, we don't put it in the extensions. We put it as
a direct
dependency for the plugin:
org.apache.maven.plugins
maven-checkstyle-plugin
org.apache.cxf
cxf-buildtools
.
..
and that works fine with 2.0.5.
Dan
I may sound insisting on this, but the fact is that we have developed
custom Checks in my company, and tens of projects are using them to
generate the checkstyle report. As 2.0.5 currently breaks our
builds, they
wouldn't be able to migrate to this new and awaited version of
Maven. Which
is sad because they're looking forward to using it...
Apart from that, everything works fine. :-)
Fabrice.
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/staging-repository/org/apache/
maven/tp://people.apache.org/%7Ejvanzyl/staging-repository/org/apache/
maven/>
maven-core/2.0.5/
Here is the JIRA roadmap:
http://jira.codehaus.org/secure/IssueNavigator.jspa ?
reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
order=DESC
+1
Thanks,
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[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: [VOTE] Release Maven 2.0.5 (take 2)
On 12 Feb 07, at 10:02 AM 12 Feb 07, Fabrice Bellingard wrote:
Hi Jason,
The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader
problem
loading a resource from a build extension Jar") still breaks my
integrations
with this last build of Maven... :-( As you tried the test project
successfully, I don't understand what can be specific to my
environment .
I've made a clean installation of Maven (no local repository and
last build
of 2.0.5), and still it breaks the test case I attached on JIRA.
Is there someone here who develops Checkstyle custom Checks and
bundles them
in a JAR (along with the configuration file) which is specified in
the build
extensions of another project? Or at least someone else who could
test the
case I described on JIRA? (with a clean installation)
I may sound insisting on this, but the fact is that we have
developed custom
Checks in my company, and tens of projects are using them to
generate the
checkstyle report. As 2.0.5 currently breaks our builds, they
wouldn't be
able to migrate to this new and awaited version of Maven. Which is sad
because they're looking forward to using it...
I checked your project in here:
http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/
core-integration-tests/src/test/resources/it0114-
extensionThatProvidesResources/
And I just ran it with the 2.0.5 that I built and put in the staging
repository:
http://rafb.net/p/humZR325.html
I'm on OS X with:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
Are you on Windows? The bane of my existence?
Jason.
Apart from that, everything works fine. :-)
Fabrice.
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/staging-repository/org/apache/
maven/
Re: [VOTE] Release Maven 2.0.5 (take 2)
Fabrice,
On Monday 12 February 2007 10:02, Fabrice Bellingard wrote:
> The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader problem
> loading a resource from a build extension Jar") still breaks my
> integrations with this last build of Maven... :-( As you tried the test
> project successfully, I don't understand what can be specific to my
> environment . I've made a clean installation of Maven (no local repository
> and last build of 2.0.5), and still it breaks the test case I attached on
> JIRA.
>
> Is there someone here who develops Checkstyle custom Checks and bundles
> them in a JAR (along with the configuration file) which is specified in the
> build extensions of another project? Or at least someone else who could
> test the case I described on JIRA? (with a clean installation)
Just FYI: we (CXF team) put our checkstyle rules into a jar bundle and use
that. However, we don't put it in the extensions. We put it as a direct
dependency for the plugin:
org.apache.maven.plugins
maven-checkstyle-plugin
org.apache.cxf
cxf-buildtools
.
..
and that works fine with 2.0.5.
Dan
>
> I may sound insisting on this, but the fact is that we have developed
> custom Checks in my company, and tens of projects are using them to
> generate the checkstyle report. As 2.0.5 currently breaks our builds, they
> wouldn't be able to migrate to this new and awaited version of Maven. Which
> is sad because they're looking forward to using it...
>
> Apart from that, everything works fine. :-)
>
> Fabrice.
>
> On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > The assemblies that people are interested in are staged here:
> >
> > http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/ >tp://people.apache.org/%7Ejvanzyl/staging-repository/org/apache/maven/>
> > maven-core/2.0.5/
> >
> > Here is the JIRA roadmap:
> >
> > http://jira.codehaus.org/secure/IssueNavigator.jspa ?
> > reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/
> > order=DESC
> >
> > +1
> >
> > Thanks,
> >
> > Jason.
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
On 12 Feb 07, at 3:24 AM 12 Feb 07, Jörg Schaible wrote: Jason van Zyl wrote on Monday, February 12, 2007 7:12 AM: On 11 Feb 07, at 11:59 PM 11 Feb 07, Jason Dillon wrote: Are there release notes on the major changes or significant fixes which we might need to adapt to and/or be able to remove local build hacks? The JIRA road map is kinda hard to scrape the relevant details from. The only thing in the list which may bite you is that the the dependency resolution is more correct, at least in terms of what we documented, in that the nearest version of a dependency will be selected. This will affect if you are not specifying all dependencies which you actually need to compile your project. Technically you should always list the dependencies that your project actually needs to compile, but we currently don't enforce that as Jorg noted. So if you are relying on transitive deps to pick up your compile time requirements you might have some issues. Specifically this: http://jira.codehaus.org/browse/MNG-2794 The rest are bug fixes. There is only the one slight behavioral change that I am aware off. Well, in any case it would be great to integrate the code of http:// jira.codehaus.org/browse/MNG-2676 into the dependencies plugin and get a release. It is a great help to analyse and fix such situations (here integrated into our internal info plugin): Here you can now help having access to the sandbox. And I think Mark has access too. The sandbox is going to be the first place that I look for integrating things. Pulling in Dan's work in the remote resources plugin was a snap. He had a working build with tests and notes, it was great. You want something like this integrated, if you put it in the sandbox and ping one of us you're chances of getting it integrate are very likely. Jason. %< = [INFO] -- -- [INFO] Building Commons Activation Project [INFO]task-segment: [info:analyse] [INFO] -- -- [INFO] Preparing info:analyse [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [info:analyse] [INFO] Used declared dependencies: [INFO]commons-io:commons-io:jar:1.3:compile [INFO]com.company.commons:company-commons-test:jar:2.0.10:test [INFO]proxytoys:proxytoys:jar:0.2.1:compile [INFO]com.company.commons:company-commons-lang:jar:2.0.6:compile [INFO]javax.activation:activation:jar:1.0.2:compile [INFO] Used undeclared dependencies: [INFO]jmock:jmock:jar:1.1.0:test [INFO]junit:junit:jar:3.8.1:test [INFO] Unused declared dependencies: [INFO]None [INFO] -- -- [INFO] BUILD SUCCESSFUL [INFO] -- -- [INFO] Total time: 19 seconds [INFO] Finished at: Mon Feb 12 09:21:38 CET 2007 [INFO] Final Memory: 6M/11M [INFO] -- -- %< = - Jörg - 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: [vote] release maven-source-plugin 2.0.3
Yes please. We need to wait a bit more. I'll make sure to send a mail with the vote result. Thanks, Stéphane On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Stephane, Would you like me to copy this over to the production repository for the release? Jason. On 11 Feb 07, at 10:42 AM 11 Feb 07, Jason van Zyl wrote: > +1 > > Thanks Stephane, > > Jason. > > On 11 Feb 07, at 5:11 AM 11 Feb 07, Stephane Nicoll wrote: > >> Hi, >> >> This release fixes all known issues. >> >> Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 >> >> ** Bug >>* [MSOURCES-6] - Sources plugin ignores resource includes/excludes >> >> ** Improvement >>* [MSOURCES-11] - When source plugin is used, it should make sure >> it is invoked during install >> >> Revision: 505872 >> >> The staging bits are available as well: >> http://people.apache.org/~snicoll/maven-staging/repo/org/apache/ >> maven/plugins/maven-source-plugin/2.0.3/ >> >> Vote opens for 72hours. >> >> My +1 >> >> Thanks, >> >> Stéphane >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release maven-source-plugin 2.0.3
Stephane, Would you like me to copy this over to the production repository for the release? Jason. On 11 Feb 07, at 10:42 AM 11 Feb 07, Jason van Zyl wrote: +1 Thanks Stephane, Jason. On 11 Feb 07, at 5:11 AM 11 Feb 07, Stephane Nicoll wrote: Hi, This release fixes all known issues. Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Revision: 505872 The staging bits are available as well: http://people.apache.org/~snicoll/maven-staging/repo/org/apache/ maven/plugins/maven-source-plugin/2.0.3/ Vote opens for 72hours. My +1 Thanks, Stéphane - 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: [VOTE] Release Maven 2.0.5 (take 2)
Hi Jason,
The issue http://jira.codehaus.org/browse/MNG-2795 ("Classloader problem
loading a resource from a build extension Jar") still breaks my integrations
with this last build of Maven... :-( As you tried the test project
successfully, I don't understand what can be specific to my environment .
I've made a clean installation of Maven (no local repository and last build
of 2.0.5), and still it breaks the test case I attached on JIRA.
Is there someone here who develops Checkstyle custom Checks and bundles them
in a JAR (along with the configuration file) which is specified in the build
extensions of another project? Or at least someone else who could test the
case I described on JIRA? (with a clean installation)
I may sound insisting on this, but the fact is that we have developed custom
Checks in my company, and tens of projects are using them to generate the
checkstyle report. As 2.0.5 currently breaks our builds, they wouldn't be
able to migrate to this new and awaited version of Maven. Which is sad
because they're looking forward to using it...
Apart from that, everything works fine. :-)
Fabrice.
On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/
Re: 2.0.5 and MNG-2794
Hi Jason, the aim of this particular test case I implemented was to reproduce the bug. I made it simple to show the issue, and I agree that if you use a class for compilation, you should specify it as a dependency in your POM. However, the problem I had when I found this issue was slightly different. "My" original code does not require commons-collections for compilation, but it relies on 2 components which require 2 different versions of this library. So commons-collections is actually required, but for runtime only (the build broke during the execution of the unit tests). As Brett said, this should be mentioned clearly in the release notes because lots of people may be surprised. Fabrice. On 2/11/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, After looking at MNG-2794 I don't think it's something we should fix change. The 2.0.4 release was working in a way contrary to our documentation in that the nearest with 2.0.4 was not being selected and it is with 2.0.5. So we either fix it and then it conflicts with what we document, or leave it and have work as documented. That particular test case also requires commons-collections for compilation and you should always specify directly any dependencies you need to compile your project. The details are in the comment, but I say we leave the behavior that is present in 2.0.5 now. http://jira.codehaus.org/browse/MNG-2794#action_87295 Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Maven 2.0.5 (take 2)
+1 Our builds run fine. Thanks, Stéphane On 2/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/ maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa? reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/ order=DESC +1 Thanks, Jason. - 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: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote: Hi, The assemblies that people are interested in are staged here: http://people.apache.org/~jvanzyl/staging-repository/org/apache/maven/maven-core/2.0.5/ Here is the JIRA roadmap: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&pid=10500&fixfor=12294&sorter/field=issuekey&sorter/order=DESC +1 Cocoon trunk builds fine, here my non-binding +1 -- Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving configuration service to plexus-registry
sounds great On 2/9/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: ok. Emmanuel Brett Porter a écrit : > Any objections to me moving the configuration service out of the > database (and take some of the bits out of application.xml) and putting > them in the registry? Basically the same thing I've just done for Archiva. > > Docs on the registry are here: > https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-components/plexus-registry/src/site/apt/index.apt > > > Cheers, > Brett > > > -- jesse mcconnell [EMAIL PROTECTED]
Re: More control over what WARNING messages are displayed
My builds produce more than 1mo of logs, and like Jason, I used seldom the warn msg. Thus, I am in favor of the -W flag. Cheers, Vincent 2007/2/12, Jason Dillon <[EMAIL PROTECTED]>: I was imagining that a -W flag would actually internally set the log level of what ever component was spitting those out. --jason On Feb 12, 2007, at 12:30 AM, Stephane Nicoll wrote: > Oh. I guess that another solution would be to lower the log level of > those messages instead. I mean it makes sense to see warning message > by default but maybe some messages are logged to this level > incorrectly. > > Stéphane > > On 2/12/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: >> +1 especially when you have 3 repositories declared in your pom and >> the dependencies are on the last one :) >> >> Cheers, >> Stéphane >> >> >> >> On 2/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> > It would really be nice if there was more control over what WARNING >> > messages that Maven spits out by default. When building off of a >> > clean repo, a bunch of '[WARNING] Unable to get resource ...' >> > messages litter the console output... which really makes it hard to >> > see what is actually going on. >> > >> > I'd like mvn to not show those by default, and have a flag to >> enable >> > them if needed... kinda like the -W flag on gcc. >> > >> > IMO these WARNING messages are only useful about 5% of the time >> when >> > strange dependency problems pop up... it would be better IMO if for >> > the remaining 95% that mvn didn't complain so much about stuff that >> > is not really a problem. >> > >> > --jason >> > >> > >> - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 2.0.5 and MNG-2794
Hope it will be in the next 2.0.6 Cheers, Vincent 2007/2/12, Trygve Laugstøl <[EMAIL PROTECTED]>: I would like to see this additional requirement too. -- Trygve Kenney Westerhof wrote: > > Yup, I agree. > > but still the case where 2 matches are equally near should be solved; > I think atm. this is either random or first/last-encountered-wins; this > should be latest (so nearest wins, if equal distance then fallback to > latest). > > But this could go in at 2.0.6 IMHO. > > -- Kenney > > Brett Porter wrote: >> Sounds right to me. Needs something mentioned in the >> announcement/release notes, though. >> >> - Brett >> >> On 12/02/2007, at 9:25 AM, Jason van Zyl wrote: >> >>> Hi, >>> >>> After looking at MNG-2794 I don't think it's something we should fix >>> change. >>> >>> The 2.0.4 release was working in a way contrary to our documentation >>> in that the nearest with 2.0.4 was not being selected and it is with >>> 2.0.5. So we either fix it and then it conflicts with what we >>> document, or leave it and have work as documented. That particular >>> test case also requires commons-collections for compilation and you >>> should always specify directly any dependencies you need to compile >>> your project. The details are in the comment, but I say we leave the >>> behavior that is present in 2.0.5 now. >>> >>> http://jira.codehaus.org/browse/MNG-2794#action_87295 >>> >>> Thanks, >>> >>> Jason. >>> >>> >>> >>> >>> - >>> 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invalid link on Maven site
Hi, On this page : http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html The link : Check out the Guide to Configuring Maven if necessary. is invalid. ++ Julien ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: [vote] release maven-source-plugin 2.0.3
+1 Vincent 2007/2/12, Emmanuel Venisse <[EMAIL PROTECTED]>: +1 Emmanuel Stephane Nicoll a écrit : > Hi, > > This release fixes all known issues. > > Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 > > ** Bug >* [MSOURCES-6] - Sources plugin ignores resource includes/excludes > > ** Improvement >* [MSOURCES-11] - When source plugin is used, it should make sure > it is invoked during install > > Revision: 505872 > > The staging bits are available as well: > http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ > > > Vote opens for 72hours. > > My +1 > > Thanks, > > Stéphane > > - > 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: 2.0.5 and MNG-2794
I would like to see this additional requirement too. -- Trygve Kenney Westerhof wrote: Yup, I agree. but still the case where 2 matches are equally near should be solved; I think atm. this is either random or first/last-encountered-wins; this should be latest (so nearest wins, if equal distance then fallback to latest). But this could go in at 2.0.6 IMHO. -- Kenney Brett Porter wrote: Sounds right to me. Needs something mentioned in the announcement/release notes, though. - Brett On 12/02/2007, at 9:25 AM, Jason van Zyl wrote: Hi, After looking at MNG-2794 I don't think it's something we should fix change. The 2.0.4 release was working in a way contrary to our documentation in that the nearest with 2.0.4 was not being selected and it is with 2.0.5. So we either fix it and then it conflicts with what we document, or leave it and have work as documented. That particular test case also requires commons-collections for compilation and you should always specify directly any dependencies you need to compile your project. The details are in the comment, but I say we leave the behavior that is present in 2.0.5 now. http://jira.codehaus.org/browse/MNG-2794#action_87295 Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More control over what WARNING messages are displayed
I was imagining that a -W flag would actually internally set the log level of what ever component was spitting those out. --jason On Feb 12, 2007, at 12:30 AM, Stephane Nicoll wrote: Oh. I guess that another solution would be to lower the log level of those messages instead. I mean it makes sense to see warning message by default but maybe some messages are logged to this level incorrectly. Stéphane On 2/12/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: +1 especially when you have 3 repositories declared in your pom and the dependencies are on the last one :) Cheers, Stéphane On 2/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > It would really be nice if there was more control over what WARNING > messages that Maven spits out by default. When building off of a > clean repo, a bunch of '[WARNING] Unable to get resource ...' > messages litter the console output... which really makes it hard to > see what is actually going on. > > I'd like mvn to not show those by default, and have a flag to enable > them if needed... kinda like the -W flag on gcc. > > IMO these WARNING messages are only useful about 5% of the time when > strange dependency problems pop up... it would be better IMO if for > the remaining 95% that mvn didn't complain so much about stuff that > is not really a problem. > > --jason > > - > 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: [vote] release maven-source-plugin 2.0.3
+1 Emmanuel Stephane Nicoll a écrit : Hi, This release fixes all known issues. Release Notes - Maven 2.x Sources Plugin - Version 2.0.3 ** Bug * [MSOURCES-6] - Sources plugin ignores resource includes/excludes ** Improvement * [MSOURCES-11] - When source plugin is used, it should make sure it is invoked during install Revision: 505872 The staging bits are available as well: http://people.apache.org/~snicoll/maven-staging/repo/org/apache/maven/plugins/maven-source-plugin/2.0.3/ Vote opens for 72hours. My +1 Thanks, Stéphane - 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: More control over what WARNING messages are displayed
Oh. I guess that another solution would be to lower the log level of those messages instead. I mean it makes sense to see warning message by default but maybe some messages are logged to this level incorrectly. Stéphane On 2/12/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote: +1 especially when you have 3 repositories declared in your pom and the dependencies are on the last one :) Cheers, Stéphane On 2/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > It would really be nice if there was more control over what WARNING > messages that Maven spits out by default. When building off of a > clean repo, a bunch of '[WARNING] Unable to get resource ...' > messages litter the console output... which really makes it hard to > see what is actually going on. > > I'd like mvn to not show those by default, and have a flag to enable > them if needed... kinda like the -W flag on gcc. > > IMO these WARNING messages are only useful about 5% of the time when > strange dependency problems pop up... it would be better IMO if for > the remaining 95% that mvn didn't complain so much about stuff that > is not really a problem. > > --jason > > - > 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: More control over what WARNING messages are displayed
+1 especially when you have 3 repositories declared in your pom and the dependencies are on the last one :) Cheers, Stéphane On 2/12/07, Jason Dillon <[EMAIL PROTECTED]> wrote: It would really be nice if there was more control over what WARNING messages that Maven spits out by default. When building off of a clean repo, a bunch of '[WARNING] Unable to get resource ...' messages litter the console output... which really makes it hard to see what is actually going on. I'd like mvn to not show those by default, and have a flag to enable them if needed... kinda like the -W flag on gcc. IMO these WARNING messages are only useful about 5% of the time when strange dependency problems pop up... it would be better IMO if for the remaining 95% that mvn didn't complain so much about stuff that is not really a problem. --jason - 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: [VOTE] Release Maven 2.0.5 (take 2)
Jason van Zyl wrote on Monday, February 12, 2007 7:12 AM: > On 11 Feb 07, at 11:59 PM 11 Feb 07, Jason Dillon wrote: > >> Are there release notes on the major changes or significant fixes >> which we might need to adapt to and/or be able to remove local >> build hacks? The JIRA road map is kinda hard to scrape the relevant >> details from. >> > > The only thing in the list which may bite you is that the the > dependency resolution is more correct, at least in terms of what we > documented, in that the nearest version of a dependency will be > selected. This will affect if you are not specifying all dependencies > which you actually need to compile your project. Technically you > should always list the dependencies that your project actually needs > to compile, but we currently don't enforce that as Jorg noted. So if > you are relying on transitive deps to pick up your compile time > requirements you might have some issues. Specifically this: > > http://jira.codehaus.org/browse/MNG-2794 > > The rest are bug fixes. There is only the one slight behavioral > change that I am aware off. Well, in any case it would be great to integrate the code of http://jira.codehaus.org/browse/MNG-2676 into the dependencies plugin and get a release. It is a great help to analyse and fix such situations (here integrated into our internal info plugin): %< = [INFO] [INFO] Building Commons Activation Project [INFO]task-segment: [info:analyse] [INFO] [INFO] Preparing info:analyse [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [info:analyse] [INFO] Used declared dependencies: [INFO]commons-io:commons-io:jar:1.3:compile [INFO]com.company.commons:company-commons-test:jar:2.0.10:test [INFO]proxytoys:proxytoys:jar:0.2.1:compile [INFO]com.company.commons:company-commons-lang:jar:2.0.6:compile [INFO]javax.activation:activation:jar:1.0.2:compile [INFO] Used undeclared dependencies: [INFO]jmock:jmock:jar:1.1.0:test [INFO]junit:junit:jar:3.8.1:test [INFO] Unused declared dependencies: [INFO]None [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 19 seconds [INFO] Finished at: Mon Feb 12 09:21:38 CET 2007 [INFO] Final Memory: 6M/11M [INFO] %< = - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
