why?
Is it mandatory? If yes I'd like to have some links.
AFAIK those files are generated.
This mean we will have to add those files for all artifacts we produce.
If one day the content change we will have to change all files in the
scm instead of only the plugin which generate that.
Seriously?
+1
On Saturday, 20 July 2013, Dennis Lundberg wrote:
Hi,
The only consumer of Maven Model Converter we have left at the Apache
Maven project is Maven One Plugin. If the vote for the retirement of
Maven One Plugin succeeds we should also retire Maven Model Converter.
The last release was
+1
Ralph
On Jul 20, 2013, at 2:13 AM, Dennis Lundberg wrote:
Hi,
Now that we have Maven 1 at End-Of-Life, I think it's time to retire
Maven One Plugin as well. It has been almost six years since the last
release. I therefor propose that we retire maven-one-plugin.
+1
Ralph
On Jul 20, 2013, at 10:26 AM, Dennis Lundberg wrote:
Hi,
The only consumer of Maven Model Converter we have left at the Apache
Maven project is Maven One Plugin. If the vote for the retirement of
Maven One Plugin succeeds we should also retire Maven Model Converter.
The last
From http://www.apache.org/dev/licensing-howto.html#source-tree-location
Location Within the Source Tree
LICENSE and NOTICE belong at the top level of the source tree. They may be
named LICENSE.txt and NOTICE.txt, but the bare names are preferred.
If you consider a release root as the top
Damned there are plenty of Apache projects which don't do that :-)
But in this case the plugin maven-remote-resources-plugin doesn't have
to be used anymore?
Because now we can have duplicate NL with possible different content.
As one will be maintained manually which mean we can miss to add
On 21 July 2013 11:48, Olivier Lamy ol...@apache.org wrote:
Damned there are plenty of Apache projects which don't do that :-)
They will have to be fixed over time.
But in this case the plugin maven-remote-resources-plugin doesn't have
to be used anymore?
Because now we can have duplicate NL
Having a copy here does indeed mean we have to maintain it, unless we use
svn:externals (but better not do that).
If I'm correct, both files contain custom 'fields', referring to the name
of the project and/or a year or date. Also, I'm always having trouble with
year ranges: suppose the
Hi
Has anyone asked if we can use generated files instead?
Many of the ASF rules are written by people that have not concidered the
fact that things such as these can be automated. Therefore many of these
rules are stated in a way that does not fit directly into the Maven way of
doing things.
On 21 July 2013 12:39, Robert Scholte rfscho...@apache.org wrote:
Having a copy here does indeed mean we have to maintain it, unless we use
svn:externals (but better not do that).
If I'm correct, both files contain custom 'fields', referring to the name of
the project and/or a year or date.
On 21 July 2013 13:09, Dennis Lundberg denn...@apache.org wrote:
Hi
Has anyone asked if we can use generated files instead?
Many of the ASF rules are written by people that have not concidered the
fact that things such as these can be automated. Therefore many of these
rules are stated in a
Op Sun, 21 Jul 2013 14:10:12 +0200 schreef sebb seb...@gmail.com:
On 21 July 2013 12:39, Robert Scholte rfscho...@apache.org wrote:
Having a copy here does indeed mean we have to maintain it, unless we
use
svn:externals (but better not do that).
If I'm correct, both files contain custom
Also, the files change relatively rarely once set up.
I thought you strongly believed in Murphy's Law...
I agree with Dennis: let's ask for the *facts* why these files are
required here. If it is because they need to be included in the
source-release file, then add them additionally
Also keep in mind, there is likely a large difference between the
LICENSE/NOTICE files that would go into a source release than would go into
the binary convenience releases. 90% of the source NOTICE/LICESE files are
just plain Apache License and the simple 4 line NOTICE.
For the binary,
On 21 July 2013 13:22, Robert Scholte rfscho...@apache.org wrote:
Op Sun, 21 Jul 2013 14:10:12 +0200 schreef sebb seb...@gmail.com:
On 21 July 2013 12:39, Robert Scholte rfscho...@apache.org wrote:
Having a copy here does indeed mean we have to maintain it, unless we use
svn:externals (but
On 21 July 2013 13:30, Robert Scholte rfscho...@apache.org wrote:
Also, the files change relatively rarely once set up.
I thought you strongly believed in Murphy's Law...
Not sure how that is relevant.
I agree with Dennis: let's ask for the *facts* why these files are required
here.
On 21 July 2013 13:38, Daniel Kulp dk...@apache.org wrote:
Also keep in mind, there is likely a large difference between the
LICENSE/NOTICE files that would go into a source release than would go into
the binary convenience releases. 90% of the source NOTICE/LICESE files are
just plain
2013/7/21 sebb seb...@gmail.com:
On 21 July 2013 13:30, Robert Scholte rfscho...@apache.org wrote:
Also, the files change relatively rarely once set up.
I thought you strongly believed in Murphy's Law...
Not sure how that is relevant.
I agree with Dennis: let's ask for the *facts* why
Hi,
I had a look at, and fixed https://jira.codehaus.org/browse/MRRESOURCES-69
When I first saw the issue I thought, hey this is in the wrong JIRA
project and went about trying to move it to the correct one. But there
is no IssueManagement in any of the POMs at
Hi
I got sidetracked by this and cannot let go of it. On the index page
of Maven Javadoc Plugin
http://maven.apache.org/plugins/maven-javadoc-plugin/
it says this:
-
...the Javadoc Plugin generates argument files and calls the Javadoc
tool as follow:
Other than in the source of the deploy plugin, do we have a document for
'deploy'?
I sporadically run into the fact that the command-line deploy plugin isn't
so hot when one has multiple classified objects.
On the one hand, I'm thinking of creating deploy:deploy-files (note the
's') with some
Hi Dennis,
The ${project.reporting.outputDirectory}/apidocs is the working directory,
whereas the javadoc executable is used with its absolute path.
So in the end it will often be:
cd ${project.reporting.outputDirectory}/apidocs
%JAVA_HOME%\bin\javadoc.exe @options @packages | @argfile
I
I just tried to cut a distribution using the existing Maven POM and it let me
get through the release:prepare phase without any issues and then failed during
the release:perform phase. I have no idea how RAT works, or who set it up but
that behavior is sub-optimal. Would probably be all right
Hi Benson,
I don't understand, because deploy:deploy-file should be able to upload
pom + artifact + classified-artifacts at once.
Robert
Op Sun, 21 Jul 2013 19:40:04 +0200 schreef Benson Margulies
bimargul...@gmail.com:
Other than in the source of the deploy plugin, do we have a
On Sun, Jul 21, 2013 at 1:52 PM, Robert Scholte rfscho...@apache.orgwrote:
Hi Benson,
I don't understand, because deploy:deploy-file should be able to upload
pom + artifact + classified-artifacts at once.
There's no provision for uploading one pom plus multiple classified
artifacts in a
On Sunday, 21 July 2013, Benson Margulies wrote:
On Sun, Jul 21, 2013 at 1:52 PM, Robert Scholte
rfscho...@apache.orgjavascript:;
wrote:
Hi Benson,
I don't understand, because deploy:deploy-file should be able to upload
pom + artifact + classified-artifacts at once.
There's no
Revert my change upping to RAT 0.9
Stupid plugin has major regression in performance, but 0.8 needs excludes
for git
If I'd had notice I'd have reverted it my self but on a phone so no access
to revert it... Once they get a proper usable release we *should* be ok...
Though they don't seem to
On Sun, Jul 21, 2013 at 2:26 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Sunday, 21 July 2013, Benson Margulies wrote:
On Sun, Jul 21, 2013 at 1:52 PM, Robert Scholte rfscho...@apache.org
javascript:;
wrote:
Hi Benson,
I don't understand, because
On Sun, Jul 21, 2013 at 2:29 PM, Benson Margulies bimargul...@gmail.comwrote:
On Sun, Jul 21, 2013 at 2:26 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Sunday, 21 July 2013, Benson Margulies wrote:
On Sun, Jul 21, 2013 at 1:52 PM, Robert Scholte rfscho...@apache.org
On 21 July 2013 14:05, Olivier Lamy ol...@apache.org wrote:
2013/7/21 sebb seb...@gmail.com:
On 21 July 2013 13:30, Robert Scholte rfscho...@apache.org wrote:
Also, the files change relatively rarely once set up.
I thought you strongly believed in Murphy's Law...
Not sure how that is
On Jul 21, 2013, at 2:29 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
Revert my change upping to RAT 0.9
Stupid plugin has major regression in performance, but 0.8 needs excludes
for git
Yup, just noticed that as well. After trying to attempt to release my
distribution 4
what's this commit?
I'm not a git master, but I suppose a rebase before committing should avoid
such things, no?
Regards,
Hervé
Le dimanche 21 juillet 2013 18:10:09 jvan...@apache.org a écrit :
Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/maven
Project:
I should, sorry about that.
On Jul 21, 2013, at 2:54 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
what's this commit?
I'm not a git master, but I suppose a rebase before committing should avoid
such things, no?
Regards,
Hervé
Le dimanche 21 juillet 2013 18:10:09 jvan...@apache.org
On 21 July 2013 19:47, Jason van Zyl ja...@tesla.io wrote:
On Jul 21, 2013, at 2:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Revert my change upping to RAT 0.9
Stupid plugin has major regression in performance, but 0.8 needs excludes
for git
Yup, just noticed that as
On 21 July 2013 14:39, denn...@apache.org wrote:
Author: dennisl
Date: Sun Jul 21 13:39:23 2013
New Revision: 1505380
URL: http://svn.apache.org/r1505380
Log:
Remove spurious blank lines in generated NOTICE file.
Modified:
On Jul 21, 2013, at 3:14 PM, sebb seb...@gmail.com wrote:
On 21 July 2013 19:47, Jason van Zyl ja...@tesla.io wrote:
On Jul 21, 2013, at 2:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Revert my change upping to RAT 0.9
Stupid plugin has major regression in
On 21 July 2013 21:23, Jason van Zyl ja...@tesla.io wrote:
On Jul 21, 2013, at 3:14 PM, sebb seb...@gmail.com wrote:
On 21 July 2013 19:47, Jason van Zyl ja...@tesla.io wrote:
On Jul 21, 2013, at 2:29 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
Revert my change upping to
On Sun, Jul 21, 2013 at 9:19 PM, sebb seb...@gmail.com wrote:
On 21 July 2013 14:39, denn...@apache.org wrote:
Author: dennisl
Date: Sun Jul 21 13:39:23 2013
New Revision: 1505380
URL: http://svn.apache.org/r1505380
Log:
Remove spurious blank lines in generated NOTICE file.
Modified:
Here you go: https://issues.apache.org/jira/browse/RAT-145
For the record the maven-license-plugin works very well and can insert the
correct licenses as well.
On Jul 21, 2013, at 5:19 PM, sebb seb...@gmail.com wrote:
On 21 July 2013 21:23, Jason van Zyl ja...@tesla.io wrote:
On Jul 21,
Hi,
@Domi, we usually mailing list to communicate here.
So yes for some reasons I don't know, this fail on my laptop but work fine
on all others. (the famous: It doesn't work on my machine :-) )
2013/7/22 Dominik Bartholdi notificati...@github.com
@olamy https://github.com/olamy is there
+1
On 21/07/2013, at 3:26 AM, Dennis Lundberg denn...@apache.org wrote:
Hi,
The only consumer of Maven Model Converter we have left at the Apache
Maven project is Maven One Plugin. If the vote for the retirement of
Maven One Plugin succeeds we should also retire Maven Model Converter.
The
(Re-posting to dev@, got confused by the cross-posting of the vote...)
+1
Thanks Dennis!
- Brett
On 20/07/2013, at 7:13 PM, Dennis Lundberg denn...@apache.org wrote:
Hi,
Now that we have Maven 1 at End-Of-Life, I think it's time to retire
Maven One Plugin as well. It has been almost six
42 matches
Mail list logo
