-1.
if I recall the discussion about plugin versions in super pom
correctly, the solution was accepted not as a way to have 100%
reprodicible build, but have reproducible builds with one version of
maven for a duration longer than a few weeks (exagerating here a bit).
So it's basically just a way t
Putting (core) plugin versions in the super POM is not a full fix for
projects to be reproductible. Users can still use other non-core
plugins without a version set.
Based on this, I'm +0 to let the superPOM plugins as is as I'd prefer a rule
to have NO plugin with version unset.
Could we move th
Hi,
I was wondering if anyone had opinions about what happens in 2.0.10,
2.1, etc with the versions of plugins that are now specified in the
super POM.
My gut feeling is that we should not upgrade these without a change to
the modelVersion - the POM should be the sole reference for build
+1
I've been using RC7 since it was uploaded (and some before that). I've
just checked the zip file from below is working as expected and
contains the correct license and notice files. I reviewed the commits
between 2.0.8 and 2.0.9 earlier.
Cheers,
Brett
On 08/04/2008, at 2:42 AM, Brian
Hi Vincent,
I was reviewing the commits for 2.0.9 and saw this one:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-project/src/main/java/org/apache/maven/profiles/activation/FileProfileActivator.java?r1=495147&r2=609976&diff_format=h
Doesn't this need to be able to use
On 8-Apr-08, at 4:09 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
What happens when the encoding is different then what is stated?
Same problem really, in how to deal with the actual versus declared.
If the declared encoding does not match the actual one, I simply
call this an user er
IMHO, the best hint for a user choose his encoding when the default
ISO-8859-1
isn't a good valuie for him, is displaying platform encoding (in "mvn -v"
output for example): it's easy, reliable, and corresponds to the value he
would have got before the change
+1, just created MNG-3509 for this.
Jason van Zyl wrote:
What happens when the encoding is different then what is stated? Same
problem really, in how to deal with the actual versus declared.
If the declared encoding does not match the actual one, I simply call this
an user error. Either he explicitly set the wrong value or forgo
duh me! Please ignore; sorry about the noise. It was the root pom.
Rahul Thakur wrote:
Is there a change in the recent release that is using 'build' folder for
output by default? I generated Eclipse projects for Continuum and all
projects have output folder set to 'build' in absence of any sp
Herve,
Just a proposal: Maven could loosen its parsing rules when it detects
versions greater than it is configured to accept. This can't be without
limits, of course, perhaps in the range of a single point release: 4.0 <=
4.0.x < 4.1. But perhaps within the 4.0.x series, it would accept undeclare
Jason van Zyl wrote:
Possibly, but you're guessing.
Guessing about how much it will be slower, yes, guessing that it will be
slower, no. Additional work, additional time. Wouldn't you agree? Then the
question becomes, is it worth to take this overhead, or how much benefit do
you expect from t
Martin von Gagern wrote:
if a newcomer like me is allowed to vote.
The more people participate in a discussion, the more likely is the result
to match public consensus rather than individual's preferences.
Suppose you have a huge source tree, mostly english ASCII, but somewhere
in there there
Le mardi 08 avril 2008, Martin von Gagern a écrit :
> +1 for the original proposal, if a newcomer like me is allowed to vote.
>
> The concept with the property, which can be set with the properties
> until the model is updated, and which can be the default expression for
> affected plugins, is simp
Le mardi 08 avril 2008, Paul Benedict a écrit :
> In Commons Validator, we updated the DTD even in point releases. I don't
> see the harm in doing the same here. After all, if the POM is 4.0.0, why
> not create a 4.0.1? It sounds like Maven 2 will have a 4.1 version.
>
> Paul
because if you use 4.0
+1 for the original proposal, if a newcomer like me is allowed to vote.
The concept with the property, which can be set with the properties
until the model is updated, and which can be the default expression for
affected plugins, is simply elegant.
Jason van Zyl wrote:
It would be reasonable
Vincent Siveton wrote:
Hi,
[SNIP]
-
scm:svn:http://svn.apache.org/repos/asf/maven/plugins/trunk/
-
scm:svn:https://svn.apache.org/repos/asf/maven/plugins/trunk/
-http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/
+
scm:svn:http://svn.apache.org/repos/asf/maven/plugi
Hi,
[SNIP]
>
> -
> scm:svn:http://svn.apache.org/repos/asf/maven/plugins/trunk/
> -
> scm:svn:https://svn.apache.org/repos/asf/maven/plugins/trunk/
> -http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/
> +
> scm:svn:http://svn.apache.org/repos/asf/maven/plugins/tags/ma
On 8-Apr-08, at 11:11 AM, Milos Kleint wrote:
+1 on Benjamin's objections to detection.
It will slow down the build (possibly significantly) while providing
little added value.
Possibly, but you're guessing.
Obviously checking the encoding on every file would be unwise. Trying
to detect whe
On 8-Apr-08, at 11:27 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from having
to know
or worry about it then yes I would use it.
Could you elaborate this a little more. Say we start easy and have a
build
with just about 100 Java
+1 on Benjamin's objections to detection.
It will slow down the build (possibly significantly) while providing
little added value.
Milos
On Tue, Apr 8, 2008 at 8:27 PM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>
> > If it's right most of the time, and it saves the user
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from having to know
or worry about it then yes I would use it.
Could you elaborate this a little more. Say we start easy and have a build
with just about 100 Java source files. Do you suggest to peek at each of
them bef
On 8-Apr-08, at 1:09 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
I'm not really sure what you meant to say. JChardet is a library
that performs a best *guess* on file encoding by peekin
Hi!
I would like to compile code not only for a given class file format
version, but also to the corresponding Java API specification. There
should be different settings for main and test code, as the main code
should be highly portable, while test code might make use of quick and
dirty featur
Hi,
This is a bit brute force, but I hope it'll be helpful.
I've written something that utilises dependency-tree to generate a set
of files representing the determined artifact tree for every POM in a
repository from a CLI [1], and a test [2] that will then re-evaluate
them with a differen
Hi Deng,
Is there any access to the servlet context to obtain this instead?
- Brett
On 08/04/2008, at 8:37 PM, [EMAIL PROTECTED] wrote:
Author: oching
Date: Tue Apr 8 03:36:50 2008
New Revision: 645833
URL: http://svn.apache.org/viewvc?rev=645833&view=rev
Log:
[MRM-123]
-configure host and
James William Dumay wrote:
Rahul,
Something like this library might help you in your quest...
http://sourceforge.net/projects/javacurses/
James
CHARVA might be useful as well:
http://www.pitman.co.za/projects/charva/
It seems both require a native DLL in order to work properly. This makes
s
2008/4/7, Benjamin Bentmann <[EMAIL PROTECTED]>:
> > I wonder if it's worth posting these as a series under the developers
> > section of the Maven site?
> >
>
> Vincent and I had already put parts of this stuff onto [0] in a section
> named "Some Pitfalls", together with a link to this mail thre
+1
Vincent
2008/4/7, Brian E. Fox <[EMAIL PROTECTED]>:
> Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
> Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
> that time. Note that there were no source changes between RC8 and this
> final build.
>
>
>
I never had this problem.
I don't think we changed something in this code.
Can you open an issue.
I'll investigate for 2.5.2
Arnaud
On Tue, Apr 8, 2008 at 9:23 AM, Rahul Thakur
<[EMAIL PROTECTED]> wrote:
>
> Is there a change in the recent release that is using 'build' folder for
> output by def
+1
Great work, thanks everyone!
-Lukas
Brian E. Fox wrote:
Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.
Rel
Hervé Boutemy wrote:
this one is more tricky, even if the change in pom.xml is a simple
addition of
an element... Don't really know how to handle this without breaking things
for Maven 2.0 when an artifact with this addition is deployed to a
repository.
Handling POM additions is a more general
Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
I'm not really sure what you meant to say. JChardet is a library that
performs a best *guess* on file encoding by peeking at a byte stream. We
don't want to base our builds
+1
Stéphane
On Mon, Apr 7, 2008 at 6:42 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
> Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
> that time. Note that there were no source changes between RC8 a
Sorry, I forgot to update my M2_HOME. Release version is ok, there is no
issue.
On Tue, Apr 8, 2008 at 10:01 AM, Bouiaw <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have downloaded apache-maven-2.0.9-bin.zip and mvn -v still return Maven
> version: 2.0.9-*RC8*.
>
> Do you observe the same issue ?
>
>
>
Hi,
I have downloaded apache-maven-2.0.9-bin.zip and mvn -v still return Maven
version: 2.0.9-*RC8*.
Do you observe the same issue ?
On Tue, Apr 8, 2008 at 9:31 AM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> +1
>
> --
> Olivier
>
> 2008/4/7, Brian E. Fox <[EMAIL PROTECTED]>:
> > Time to vote on
Paul Benedict wrote:
My only concern is that the encoding kind of assumes one kind of source
file.
We are well aware that different kind of text files may use different
encodings. A simple example is using UTF-8 for Java source files and Latin-1
for properties files.
However, the primary goal
+1
--
Olivier
2008/4/7, Brian E. Fox <[EMAIL PROTECTED]>:
> Time to vote on the final Maven 2.0.9 Release. We went through 8 Release
> Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
> that time. Note that there were no source changes between RC8 and this
> final build.
>
Is there a change in the recent release that is using 'build' folder for
output by default? I generated Eclipse projects for Continuum and all
projects have output folder set to 'build' in absence of any specified
folders. The online plugin docs suggest otherwise; bug?
Rahul
Brian E. Fox w
38 matches
Mail list logo
