On Fri, 18 Apr 2008 04:11:19 Christian Edward Gruber wrote:
> Having said that, a simpler option would be to have - or . parsed as
> equivalent punctuation tokens, and have numerical ordering if it's
> convertable to a number or lexical ordering if not, on each item
> between the punctuations. so:
I know that maven2 is convention over anything else... a more general but
consistent versioning scheme will help people transition, and help maven
packages artifacts stay consistent with upstream sources.
You could even have the release plugin map the version to the maven2 way with
beta, alpha,
With two caveats...
1)
A leading zero turns a number into a string (not a zero by itself)
2)
How to you apply the -! rule that I use all the time which stops a match
against -SNAPSHOT e.g. [2,3-!) will not match 3-SNAPSHOT.
Perhaps say ! means !"" and which means so that it can only match the
If we were to split the version string into components on - and . and _ and
also split on transitions from number to letters then use the ordering rules
at each component as defined here...
Examples of version to components split
1.0 ==> 1, 0
1.0-beta1 ==> 1, 0, beta, 1
1-SNAPSHOT ==> 1, SNAPSHO
I made this into a tutorial:
http://www.dzone.com/links/how_to_share_resources_across_projects_in_maven.html
-Original Message-
From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 4:27 PM
To: Maven Developers List
Subject: Re: Inheriting resources
Sorry to
Issue Subscription
Filter: Design & Best Practices (29 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-3313NetBeans projects, more than ant project, more than fre
ya, I remember kenney's stuff on that, there was a thread on the mailing
list and then the wiki...good stuff
jesse
On Thu, Apr 17, 2008 at 8:54 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> I believe Kenney wrote a proposal on the wiki, and maybe even some code,
> for some changes - it would be
I believe Kenney wrote a proposal on the wiki, and maybe even some
code, for some changes - it would be worth reviewing them too.
- Brett
On 18/04/2008, at 12:27 AM, Paul Gier wrote:
While looking into this, I noticed that the release plugin uses it's
own version parsing instead of the pars
Thanks Milos for this review.
I'm starting to merge changes into plugins trunks.
Hervé
Le mercredi 16 avril 2008, Milos Kleint a écrit :
> +1 on integrating it.
> it's non intrusive and does what I would expect by default while
> allowing me to override the behaviour for some plugins.
> it makes
The Apache Maven team is pleased to announce the release of the Maven Ant
Tasks, version 2.0.9.
You can find the binaries here:
http://maven.apache.org/download.html
You can find the release notes here:
http://maven.apache.org/ant-tasks-release-notes.html
Enjoy,
-The Apache Maven team
---
Sure, I will send one tonight.
-Original Message-
From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 4:27 PM
To: Maven Developers List
Subject: Re: Inheriting resources
Sorry to ask but could you provide me with an example please? Because I just
don't see t
Sorry to ask but could you provide me with an example please? Because I just
don't see those options in the documentation and I don't know where to put
them.
2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>:
>
> You can specify includeArtifactId=xxx and includeGroupId=xxx and this
> essentially narrows
Here are the results of the vote:
+1 (binding): Jason van Zyl, Brian E. Fox, Jesse McConnell, Olivier Lamy
+1 (non-binding): Thomas Tardy, Hervé Boutemy
The vote has passed and I will move the artifacts over to the central repo.
Thanks to everyone who voted!
Le lundi 14 avril 2008, Hervé BOUTE
+1
--
Olivier
2008/4/17, Hervé BOUTEMY <[EMAIL PROTECTED]>:
> still missing 2 PMC votes...
>
> Le lundi 14 avril 2008, Hervé BOUTEMY a écrit :
>
> > Hi,
> >
> > We solved 8 issues:
> > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=
> >Html&version=13935
> >
> >
You can specify includeArtifactId=xxx and includeGroupId=xxx and this
essentially narrows down to the one you want. (you could also do type=zip etc
and they can be combined)
-Original Message-
From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 3:51 PM
To:
Thinking
MavenProject has the list of resources, right?
http://maven.apache.org/ref/2.0.4/maven-project/apidocs/org/apache/maven/project/MavenProject.html#getResources()
So, exists any kind of dependency/plugin/whatever who allow me to define the
dependency A must be maped into resources list
But how can I choose specifically this one and not unpack all the other
dependencies in the same place. I didn't find any configuration showing that
level of granularity.
2008/4/17, Brian E. Fox <[EMAIL PROTECTED]>:
>
> You can use dependency:unpack/unpack-dependencies to retrieve them and put
> '
+1 I'll risk resting on brian and jason so we can get this out asap :)
On Thu, Apr 17, 2008 at 2:47 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:
> +1, the bootstraps are using them and are working.
>
> -Original Message-
> From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
> Sent: Thursday, Apr
You can use dependency:unpack/unpack-dependencies to retrieve them and put 'em
were you need 'em
-Original Message-
From: Sebastien ARBOGAST [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 3:40 PM
To: Maven Developers List; [EMAIL PROTECTED]
Subject: Re: Inheriting resources
I'
+1, the bootstraps are using them and are working.
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 3:37 PM
To: Maven Developers List
Subject: Re: [VOTE] Release Maven Ant Tasks version 2.0.9
still missing 2 PMC votes...
Le lundi 14 avril 2
I've been trying to make it work with assembly plugin but configuration is
quite heavy. I manage to archive my configuration files in a zip file, but
then how do I configure the other modules to unpack the archive (just this
one) to the right directory? Far too much hassle.
I'm starting to think t
still missing 2 PMC votes...
Le lundi 14 avril 2008, Hervé BOUTEMY a écrit :
> Hi,
>
> We solved 8 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11533&styleName=
>Html&version=13935
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueN
Don't hard code anything, then if there is already a value, use that otherwise
prompt.
-Original Message-
From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 2:38 PM
To: Maven Developers List
Subject: Re: prompt behaviour changes was: [VOTE] Release Maven Arche
So to sum up on the behaviour,
What is desired is :
- ask for each property (proposing a default value when guessed)
- then ask for confirmation.
Currently the configuration behaviour do not know from where
comes the default values. They can come from :
- some hard coded (groupId=com.company, arti
Hi
Can you please file this in JIRA [1], otherwise it might get lost in the
traffic. Please include a sample project (if you can) and the complete
output log that you get.
Note that maven-pmd-plugin requires a pmd jar file that can be used with
Java 1.4, hence the "jdk14" classifier.
[1] h
While looking into this, I noticed that the release plugin uses it's own version
parsing instead of the parsing in the maven-artifact component.
https://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/versions/DefaultVersionInfo.ja
Would it not be helpful to have a version pattern, somewhat the way
dates have patterns for parsing, so that there can be the default, an
osgi standard pattern, and a custom one specified in the pom?
So a pattern might be xx.[yy.[zz.[pp]]] or xx.yy.pp-
Where xx == major, yy == medium, zz
I submitted a patch for 159.
I didn't apply it because I don't know very well your code.
I added some comments on the issue.
cheers
arnaud
On Thu, Apr 17, 2008 at 2:32 PM, Raphaël Piéroni
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> The current vote is cancelled untill i (or any one which would like to
Same thing for me. I didn't notice it. I prefer the older behavior.
cheers
arnaud
On Thu, Apr 17, 2008 at 3:41 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I also think the new defaults aren't really helpful. IMO it should support
> two modes: prompting the way it does in alpha-1/2 and by pass
Ok, I understand. So I guess I'll try to work on this for 2.1?
Brian E. Fox wrote:
I honestly don't think such changes can or should be made in 2.0.x. We
are nine releases into this branch, the focus needs to be on stabilizing
it not adding more dangerous changes.
-Original Message-
Fr
I honestly don't think such changes can or should be made in 2.0.x. We
are nine releases into this branch, the focus needs to be on stabilizing
it not adding more dangerous changes.
-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 11:12 AM
To: Ma
Yes, this would be ideal for me too :)
How difficult would it be to allow the version parsing to be loaded as a build
extension? That seems like the best solution.
Could this be implemented in 2.0.x?
Brian E. Fox wrote:
I agree with that sentiment. I think the pluggable nature of the handler
Brett Porter wrote:
On 17/04/2008, at 9:39 PM, Brian E. Fox wrote:
These kinds of changes in the 2.0.x branch concern me. There's no way to
predict what impact this will have out there.
Yes, I thought it'd just be for trunk?
There were two things that occurred to me:
- anything relying on
I agree with that sentiment. I think the pluggable nature of the handler
needs to be able to handle multiple definitions in the same pom. Ie just
because you want the osgi behavior on one dependency may not mean you
want to switch your entire build.
-Original Message-
From: Ralph Goers [ma
The mechanism for Artifact version checking should really be pluggable.
It looks like it was originally intended to be (why else would it be
named DefaultArtifactVersion and implement an interface), but the code
just does new DefaultArtifactVersion. I would prefer to have this fixed
before doi
We still have to provide a migration path to 2.1 even if we make the
changes there...it just delays the problem. But I'm exactly concerned
about this reversing the current range behavior. It seems like we need
ways to specify the format.
-Original Message-
From: Brett Porter [mailto:[EMAIL
Since it doesn't change the parsing of the standard maven version string, I
think the risk is pretty low. I see it as basically better handling of one type
of non-standard format. But I understand your concern, that's why I brought it
up for discussion ;)
Brian E. Fox wrote:
These kinds o
On 17/04/2008, at 9:39 PM, Brian E. Fox wrote:
These kinds of changes in the 2.0.x branch concern me. There's no
way to
predict what impact this will have out there.
Yes, I thought it'd just be for trunk?
There were two things that occurred to me:
- anything relying on the Maven format won
I also think the new defaults aren't really helpful. IMO it should support two
modes: prompting the way it does in alpha-1/2 and by passing the info in the
form of properties.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 5:27 AM
To: Mave
These kinds of changes in the 2.0.x branch concern me. There's no way to
predict what impact this will have out there.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 5:23 AM
To: Maven Developers List
Subject: Re: Change to artifact version h
Hello,
Looking in
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-pmd-plugin/2.3/maven-pmd-plugin-2.3.pom
I found out it depends on pmd-jdk14-4.1.1.jar
Now, this Jar does not contain net.sourceforge.pmd.rules
.basic.AvoidMultipleUnaryOperators
but the plugin implementation is lookin
Hi,
The current vote is cancelled untill i (or any one which would like to help)
fix the archetype-159 bug.
Thanks to all the reviewers.
I will try to reschedule a new vote asap.
Regards,
Raphaë
yes, with pleasure.
Arnaud
On Thu, Apr 17, 2008 at 2:30 PM, Raphaël Piéroni
<[EMAIL PROTECTED]> wrote:
> Fine,
> I will then try to fix this.
>
> Arnaud, can i send you a request of verifycation
> when i get this fixed ?
>
> Regards,
>
> Raphaël
>
> 2008/4/17 Arnaud HERITIER <[EMAIL PROTECT
Fine,
I will then try to fix this.
Arnaud, can i send you a request of verifycation
when i get this fixed ?
Regards,
Raphaël
2008/4/17 Arnaud HERITIER <[EMAIL PROTECTED]>:
> Hi Raphael,
>
> -1,
>
> I encountered also this issue :
> https://jira.codehaus.org/browse/ARCHETYPE-159 with alpha-
2008/4/17 Brett Porter <[EMAIL PROTECTED]>:
>
> On 15/04/2008, at 7:30 PM, Raphaël Piéroni wrote:
>
>
> >
> > > I did find a bad license header here:
> > >
> archetype-common/src/test/java/org/apache/maven/archetype/test/InternalCatalogFromWiki.java,
> > > but it's not a blocker.
> > >
> > Do you
Hi Raphael,
-1,
I encountered also this issue :
https://jira.codehaus.org/browse/ARCHETYPE-159 with alpha-2 and
alpha-3
Can you have a look at it please.
I think it is important if it is not solved in alpha-3. We cannot
use the generate mojo. It tries to download archetypes (I discovered
I tested the 2.0.9 ant task regarding the
http://jira.codehaus.org/browse/MANTTASKS-108 MANTTASK-108 and it's working
well. Therefore +1.
Thanks Herve for the quick implementation!!!
Regards,
Thomas
On 14-Apr-08, at 1:52 PM, Hervé BOUTEMY wrote:
> Hi,
>
> We solved 8 issues:
> http://jira.cod
On 15/04/2008, at 7:30 PM, Raphaël Piéroni wrote:
I did find a bad license header here:
archetype-common/src/test/java/org/apache/maven/archetype/test/
InternalCatalogFromWiki.java,
but it's not a blocker.
Do you have a tool for checking the license? or did you check by hand
each files?
I
On 16/04/2008, at 1:19 AM, Raphaël Piéroni wrote:
I found a regression in :generate -
1) the default (15) is no longer present
This is not intended.
This is a side effect of the new version of the internal catalog.
Brett, may you please create a issue for it, i think we can live
with that
I haven't yet applied it, but at first thought it seems a reasonable
change.
- Brett
On 16/04/2008, at 6:37 AM, Paul Gier wrote:
Hi everyone,
I'd like to make a small change to the artifact version parsing. We
currently have several released projects that use a non-standard
version sch
I didn't see this attached. If it can reuse as much of the existing
wagon implementations as possible, I can see some value in this to
make releases easier - though maybe a separate plugin hooked into the
release process makes more sense?
- Brett
On 13/04/2008, at 11:44 PM, david delbecq w
Thanks Dennis for fixing the site
Raphaël
2008/4/16, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
> Date: Wed Apr 16 14:46:20 2008
> New Revision: 648866
>
> URL: http://svn.apache.org/viewvc?rev=648866&view=rev
> Log:
> o Fix typos.
> o Add some formatting.
>
> Modified:
>
52 matches
Mail list logo
