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 bimargul...@gmail.comwrote:
I've made three releases that all need to be in the board report.
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=1137904view=rev
Log:
[MDEPLOY-137] Allow deployment of multiple side artifacts at the same time
via the CLI
[snip]
+
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
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
configuration
forCliUseOnlyFiles.../forCliUSeOnlyFiles
/configuration
but it's still tied to the property files so that
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
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 June 2011 10:47, Stephen Connolly stephen.alan.conno...@gmail.comwrote:
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
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
ralph.go...@dslextreme.com wrote:
-1
I have used my dslextreme.com email for years and now have a couple dozen ASF
email lists on it.
Thanks.
2011/6/23 Arnaud Héritier aherit...@gmail.com:
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
bimargul...@gmail.comwrote:
I've made three releases
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
kristian.rosenv...@gmail.com wrote:
I am also sceptical to
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
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
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.
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 pg...@redhat.com wrote:
The way we've dealt with this type of thing in
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 we
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
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 jdca...@commonjava.org 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
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 jdca...@commonjava.org wrote:
On 6/23/11 10:17 AM,
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).
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
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
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
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
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
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
25 matches
Mail list logo
