Stephen,
You mentioned that you might find the time to merge the
surefire/failsafe sites into one site. I'm wondering if that'd be now ;)
I'm mostly concerned about getting the structure set up correctly and
all the links working and stuff like that.
Since I'm a real wiz at merging *files*
Issue Subscription
Filter: Design & Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
This problem resulted because java.net projects are being moved into
Central. There was a conflict between what they had and what's in
Central. The old artifact is being put back in place. People that want
to correct one will have to use the new gav.
The point about why this shouldn't be changed i
I worry a lot about reproducibility and people's builds changing all of a
sudden. Changing a released artifact screws with people's builds.
A lot of Maven users use central with very little knowledge and they will
surely not understand what has happened. Also, the old artifact will stlll
stay in lo
I think it gets a bit more complicated. javax.jstl-1.2 was definitely available
on the java.net m2 repo. Thus you had 2 artifacts with the same GAV but
_different_ content. This has been a russian roulette so far depending if the
java.net repo got sucked upfront or not.
We now track the origin
Why is this a better solution than putting in a relocation POM that
points to the corrected groupId:artifactId? Seems like you would never
ask for jstl 1.2 and be happy getting back jstl 1.1, so that's a problem
that needs a solution.
Perhaps the removal was only half of the solution, and what
On 07:56:25 PM Thursday, June 23, 2011 Anders Hammar wrote:
> But of course. But if you read the jira ticket, you'll notice that the
> reason for the change was that the old artifact was simply the wrong one.
Simply! So you're saying that keeping the wrong artifact is better than fixing
it with t
But of course. But if you read the jira ticket, you'll notice that the
reason for the change was that the old artifact was simply the wrong one.
But that does not validate removing it. It should have bean kept and the
correct one should have bean deployed with a patch version number (or
similar).
I'll find out more about what happened here. In general things don't
get changed or removed once it hit's Central. There are sometimes
judgement calls that need to be made so it's not iron clad.
On Thu, Jun 23, 2011 at 10:26 AM, John Casey wrote:
>
>
> On 6/23/11 10:17 AM, Anders Hammar wrote:
>>
could you put a redirect to the new artifact in?
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Thu, Jun 23, 2011 at 09:26, John Casey wrote:
>
>
> On 6/23/11 10:17 AM, Anders Hammar wrote:
>>
>> My position is that artifacts at central should never ever change. If
>> there's something wrong
On 6/23/11 10:17 AM, Anders Hammar wrote:
My position is that artifacts at central should never ever change. If
there's something wrong with one, a new version needs to be deployed.
A released artifact is immutable.
There could always be exceptions to this, though, especially where
intellect
If we wanted to take a more automated approach to the voting process as
a whole, you might be able to get the uniformity necessary. There are
quite a few steps to calling a vote, and even the vote email itself has
a certain "best practice" format. If we generated that vote email
somehow, then w
My position is that artifacts at central should never ever change. If
there's something wrong with one, a new version needs to be deployed.
A released artifact is immutable.
/Anders
On Thu, Jun 23, 2011 at 16:11, Paul Gier wrote:
> The way we've dealt with this type of thing in the JBoss reposi
The way we've dealt with this type of thing in the JBoss repository is
we move it to a "deprecated" repository. So if people need to keep
their builds working while migrating to the new GAV, they can add the
deprecated repo to a profile in their settings. This process seems to
work ok for us. Ma
I'm not concerned with full automation. My current vision is that the
tool pops up and says:
I think I got these votes from these people: OK?
Note that i can't make the vote parser itself 100% reliable since
people don't use the [X] convention.
Also, as we all know, the site is frequently not up
If you're supposed to do things fully automatic I think it should be
a little more secure than that.
Basically I just need a file of hash->pmc member id mappings. If things
need to be
simple we could just put it in a plaintext file on the site.
Using a formula like gravatar does
(http://en.gr
This scheme does not have to be secure. How about asking people to
just toss their memberid in the form availid:royfielding into the
message body if you don't use an apache.org from?
On Thu, Jun 23, 2011 at 1:02 AM, Kristian Rosenvold
wrote:
> I am also sceptical to being forced into using the as
Thanks.
2011/6/23 Arnaud Héritier :
> Done
>
> * Maven Changes Plugin 2.6 (2011-06-23)
> * Maven Plugins Parent 21 (2011-06-18)
> * Maven Parent 20 (2011-06-17)
>
> Arnaud
>
> On Thu, Jun 23, 2011 at 12:47 AM, Benson Margulies
> wrote:
>
>> I've made three releases that all need to be in the b
On gmail there's a somewhat recent addition to the config system for
this. However, it's clearly a nonstarter.
On Thu, Jun 23, 2011 at 12:45 AM, Ralph Goers
wrote:
> -1
>
> I have used my dslextreme.com email for years and now have a couple dozen ASF
> email lists on it. rgo...@apache.org forwa
On 23 June 2011 10:47, Stephen Connolly wrote:
> the only really safe separators I see are , ; / and \
>
>
And they're not 100% safe anyway
Otherwise xargs wouldn't need that \0 terminator mode
Can you file a jira for that and assign it to me... I'll think about how to
tweak that for the single property case...
inferring file type is tricky... e.g. .tar.gz
and you really need two clear separators or else you end up with something
like
; as the item sep
filename,type/classifier
e.g.
On 23/06/2011, at 5:15 PM, Stephen Connolly wrote:
> This is for the CLI
>
> mvn deploy:deploy-file -Dpom=myart.pom -Dfile=myart.jar
> -Dsources=myart-sources.jar -Djavadoc=myart-javadoc.jar
> -Dfiles=myart-src.zip,myart-src.tar.gz,myart-bin.zip,myart-bin.tar.gz
> -Dtypes=zip,tar.gz,zip,tar,gz -
Or are you talking about when people are configuring within the pom
in which case I don't mind prefixing them with
forCliUseOnly
so that the configuration block would be
...
but it's still tied to the property "files" so that on the CLI I just type
-Dfiles=...
On 23 June 2011 10:15, Steph
This is for the CLI
mvn deploy:deploy-file -Dpom=myart.pom -Dfile=myart.jar
-Dsources=myart-sources.jar -Djavadoc=myart-javadoc.jar
-Dfiles=myart-src.zip,myart-src.tar.gz,myart-bin.zip,myart-bin.tar.gz
-Dtypes=zip,tar.gz,zip,tar,gz -Dclassifiers=src,src,bin,bin
Do we really want to force people t
On 21/06/2011, at 4:25 PM, steph...@apache.org wrote:
> Author: stephenc
> Date: Tue Jun 21 08:25:23 2011
> New Revision: 1137904
>
> URL: http://svn.apache.org/viewvc?rev=1137904&view=rev
> Log:
> [MDEPLOY-137] Allow deployment of multiple side artifacts at the same time
> via the CLI
>
[snip]
Done
* Maven Changes Plugin 2.6 (2011-06-23)
* Maven Plugins Parent 21 (2011-06-18)
* Maven Parent 20 (2011-06-17)
Arnaud
On Thu, Jun 23, 2011 at 12:47 AM, Benson Margulies wrote:
> I've made three releases that all need to be in the board report.
>
> -
26 matches
Mail list logo
