te:
Howdy,
So let me get this straight: you are now suffering from
"unknown branches and/or junkyard of branches in canonical repo"?
While you still refuse to use forks?
T
On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty Harold
wrote:
Can I delete the maven-3.x-next branch in
t; > So let me get this straight: you are now suffering from
> > "unknown branches and/or junkyard of branches in canonical repo"?
> > While you still refuse to use forks?
> >
> > T
> >
> > On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty Harold
PM
To: Maven Developers List
Subject: Re: maven-3.x-next
not Elli's fault，github is somehow broken at repo manage system...
There SHALL have ability to make repo group，and in each group allow same-name
repos...like what gitlab did.
but now we can only use multi account， or lots of
on
Amess
From: Xeno Amess
Sent: Friday, January 24, 2025 9:04:42 PM
To: Maven Developers List
Subject: Re: maven-3.x-next
not Elli's fault，github is somehow broken at repo manage system...
There SHALL have anility to make repo group，and in each group allow damr-na
Amess
From: Tamás Cservenák
Sent: Friday, January 24, 2025 8:59:28 PM
To: Maven Developers List
Subject: Re: maven-3.x-next
I really wonder what will some new Elliotte in near or far future say
about branches named "utils", "unused", "mdo", "
; > Howdy,
> >
> > So let me get this straight: you are now suffering from
> > "unknown branches and/or junkyard of branches in canonical repo"?
> > While you still refuse to use forks?
> >
> > T
> >
> > On Fri, Jan 24, 2025 at 12:58 PM Ell
Oh Gary sometimes you are just too mean
(btw I strongly suggest fork.)
发件人: Gary Gregory
发送时间: 星期五, 一月 24, 2025 8:45:22 下午
收件人: Maven Developers List
主题: Re: maven-3.x-next
Thank for bringing a smile to my face this morning.
Gary
On Fri, Jan 24, 2025, 07:28
e to use forks?
>
> T
>
> On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty Harold
> wrote:
> >
> > Can I delete the maven-3.x-next branch in the github repo? It appears
> > to be a relic of circa 3.5.0 and is not the actual current 3.x branch,
> > which I&#
Cservenák wrote:
>
> Howdy,
>
> So let me get this straight: you are now suffering from
> "unknown branches and/or junkyard of branches in canonical repo"?
> While you still refuse to use forks?
>
> T
>
> On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty H
Howdy,
So let me get this straight: you are now suffering from
"unknown branches and/or junkyard of branches in canonical repo"?
While you still refuse to use forks?
T
On Fri, Jan 24, 2025 at 12:58 PM Elliotte Rusty Harold
wrote:
>
> Can I delete the maven-3.x-next bran
Can I delete the maven-3.x-next branch in the github repo? It appears
to be a relic of circa 3.5.0 and is not the actual current 3.x branch,
which I'm still looking for.
--
Elliotte Rusty Harold
elh...@ibiblio.org
---
Olivier opened a Jira issue about this [1]
let's work here
Regards,
Hervé
[1] https://issues.apache.org/jira/browse/MNG-7430
Le dimanche 13 mars 2022, 15:29:01 CET Tibor Digana a écrit :
> Hello Maven developers,
>
> I want to inform you about some compliance issues between the Javadoc of
> M
Hello Maven developers,
I want to inform you about some compliance issues between the Javadoc of
Maven Plugin API and the Maven Core 3.x behavior. I am only a messenger
providing the facts and I would like the community to post the opinions and
finally a concrete fix(es).
The Maven 3 reports with
in a few days
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > [1]
> > > > > >
> > > http://maven.apache.org/shared/maven-verifier/xref/
t/
> > > > > ForkedLauncher.html#L60
> > > > >
> > > > > [2]
> > > > >
> > http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
> > > > > maven/cli/MavenCli.html#L262
> > > > >
; ite/src/test/java/org/apache/maven/it/
> > > > MavenITmng5889CoreExtensionsTest.java#L57
> > > >
> > > > Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > > > > sure tempting :-)
> > > > > But is is the same classloader mec
gt; > >
> > > Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > > > sure tempting :-)
> > > > But is is the same classloader mechanism as a "normal" Maven run?
> > > > (should
> > > > be really close but not s
trial and error :)
Regards,
Hervé
Le dimanche 26 mars 2017, 08:47:56 CEST Apache Jenkins Server a écrit :
> See
> https://builds.apache.org/job/maven-3.x-jenkinsfile/job/Jenkins-tools-names
> /1/
-
To unsubscrib
lan.conno...@gmail.com> wrote:
> > > > Have we some of the tests running in both modes?
> > > >
> > > > Specifically at least 4625 as it caught some interesting CLI parsing
> > > > issues, but there may be a couple more
> > > >
; >
> > > Specifically at least 4625 as it caught some interesting CLI parsing
> > > issues, but there may be a couple more
> > >
> > > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy wrote
t; > >
> > > Specifically at least 4625 as it caught some interesting CLI parsing
> > > issues, but there may be a couple more
> > >
> > > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy
> wrote:
> > > >
t; > as you can see, in embedded mode, core ITs can run in 17 minutes, when
> > > in
> > > classic mode they run in 1h30
> > >
> > > any objection to merge this embedded mode into master?
> > >
>
, when in
> > classic mode they run in 1h30
> >
> > any objection to merge this embedded mode into master?
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 24 mars 2017 04:17:49 CET, vous
lassic mode they run in 1h30
>
> any objection to merge this embedded mode into master?
>
> Regards,
>
> Hervé
>
> Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > See
> https://builds.apache.org/job/m
as you can see, in embedded mode, core ITs can run in 17 minutes, when in
classic mode they run in 1h30
any objection to merge this embedded mode into master?
Regards,
Hervé
Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/
Am 03/21/17 um 03:57 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6112/1/
>
Seems "null" does not always indicate a successful build. Can someone
take a look at this please and maybe update the Jenkinsfile to have a
subject ind
the message "null" here still happens for a failed build: our Jenklinsfile does
not look to be reliable when sending emails
Regards,
Hervé
Le jeudi 23 février 2017, 18:55:11 CET Apache Jenkins Server a écrit :
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/56/
we are back to a blue build! w00t!
On 23 February 2017 at 12:48, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> I pushed a different work-around in https://github.com/apache/
>
I pushed a different work-around in
https://github.com/apache/maven/commit/5cce371c8aee5d957d9b24e46cddc939a15aff40
This also adds the *magic* resolveScm step, so if you have an integration
test branch with the same name as your maven core branch, then the branch
should be automatically detected a
Am 02/23/17 um 09:07 schrieb Stephen Connolly:
> Yes. Infra updated some Jenkins plugins and now the Windows path is too
> long.
>
> I need them to upgrade to branch-api 2.0.7 (released yesterday) and set a
> system property to resolve the issue
Good to know. I updated various build jobs of the "
ver:
> > See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/54/
> >
>
> Turns out the "null" in the subject does not indicate a successful
> build. Maven master currently does not build successfu
Am 02/23/17 um 06:18 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/54/
>
Turns out the "null" in the subject does not indicate a successful
build. Maven master currently does not build successfully.
Regard
Hi,
Done so...
Kind regards
Karl Heinz Marbaise
On 07/02/17 22:34, Bhowmik, Bindul wrote:
Hello,
It looks like two builds from the maven-3.x-jenkinsfile Jenkins
project are stuck on the Windows nodes (on both windows machines).
Both seem to be running for over 6 days and are holding up 3
Hello,
It looks like two builds from the maven-3.x-jenkinsfile Jenkins
project are stuck on the Windows nodes (on both windows machines).
Both seem to be running for over 6 days and are holding up 3 executors
(possibly slowing down other builds that want to run on Windows).
The builds are
g, rfscho...@apache.org,
notificati...@maven.apache.org
Envoyé: Samedi 12 Novembre 2016 21:43:19
Objet: maven-3.x Jigsaw - Build # 10 - Fixed
The Apache Jenkins build system has built maven-3.x Jigsaw (build #10)
Status: Fixed
Check console output at
https://builds.apache.org/job/maven-3.x%20Jigsaw/
yay!
- Mail original -
De: "Apache Jenkins Server"
À: schu...@apache.org, micha...@apache.org, rfscho...@apache.org,
notificati...@maven.apache.org
Envoyé: Samedi 12 Novembre 2016 21:43:19
Objet: maven-3.x Jigsaw - Build # 10 - Fixed
The Apache Jenkins build system has built
re to
make a release of it.
Robert
On Sun, 23 Oct 2016 18:50:20 +0200, Apache Jenkins Server
wrote:
The Apache Jenkins build system has built maven-3.x Jigsaw (build #2)
Status: Still Failing
Check console output at
https://builds.apache.org/job/maven-3.x%20Jigsaw/2/ to view the re
m.xml actually, I think) that's coded
into the Model class in the maven-model project/artifact.
-Original Message-
From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
Sent: Wednesday, September 04, 2013 1:01 PM
To: dev@maven.apache.org
Subject: Re: maven 3.x and parent pom dependencies
]
Sent: Wednesday, September 04, 2013 1:01 PM
To: dev@maven.apache.org
Subject: Re: maven 3.x and parent pom dependencies
John Dix wrote:
> Hello,
>
> I am wanting to determine how maven determines where parent poms are
> if the tag is not in the section of a pom. Can
> someone ple
John Dix wrote:
> Hello,
>
> I am wanting to determine how maven determines where parent poms are if
> the tag is not in the section of a pom. Can
> someone please point me to where in the source code I should set a
> breakpoint and start look for this?
A missing relativePath element and the f
Hello,
I am wanting to determine how maven determines where parent poms are if the
tag is not in the section of a pom. Can someone please
point me to where in the source code I should set a breakpoint and start look
for this?
Thanks!
John "Caolan" Dix
Programming Sr. SME, Digital Commerce
A
On Friday, 17 August 2012, Stanislav Ochotnicky wrote:
>
> Quoting Stephen Connolly (2012-08-17 13:32:54)
> > If in 50 years time that means that there is still some Maven plugins
> that
> > depend on some of the published Maven APIs from Maven 2.0 then that is a
> > success on behalf of the Maven
Quoting Stephen Connolly (2012-08-17 13:32:54)
> If in 50 years time that means that there is still some Maven plugins that
> depend on some of the published Maven APIs from Maven 2.0 then that is a
> success on behalf of the Maven developers, not a failure to force people to
> upgrade.
I honestl
dge that is
> > > > something that may be beyond their control. Forcing plugin
> >
> > dependencies up
> >
> > > > without a valid driving requirement is just forcing unnecessary pain
> >
> > on the
> >
> > > > end users.
> >
knowledge that is
>> > > something that may be beyond their control. Forcing plugin
>> dependencies up
>> > > without a valid driving requirement is just forcing unnecessary pain
>> on the
>> > > end users.
>> > >
>> > > IMHO features sh
up
> > > without a valid driving requirement is just forcing unnecessary pain
> on the
> > > end users.
> > >
> > > IMHO features should drive the upgrading of dependencies, nothing else.
> > >
> >
> > +1
> >
> > There is
Quoting Chris Graham (2012-07-30 15:43:31)
> I work with a lot of older (sometimes out of service software [customers pay
> a fortune but are prepared to live with it]) so I'm generally a fan of the
> lowest common denominator.
Indeed nothing wrong with it
>
> What do you hope to achieve by the
.
> >
> > IMHO features should drive the upgrading of dependencies, nothing else.
> >
>
> +1
>
> There is little value in updating plugins to use Maven 3.x components for the
> sake of it. The reason we spent so much time making sure that 3.x runs older
>
There is little value in updating plugins to use Maven 3.x components for the
sake of it. The reason we spent so much time making sure that 3.x runs older
components was to ensure no one has to do this.
> -Stephen
>
> On 30 July 2012 12:44, Stanislav Ochotnicky wrote:
>
>>
s general feeling about updating maven plugins from
> depending on Maven 2.x artifacts to their Maven 3.x counterparts.
>
> I am aware not all m2 artifacts have equivalents in m3 (i.e.
> maven-project, maven-artifact-manager and few others). Things have moved
> around somewhat (i.e
solve?
-Chris
On 30/07/2012, at 9:44 PM, Stanislav Ochotnicky wrote:
> Hi everyone,
>
> I am wondering what is general feeling about updating maven plugins from
> depending on Maven 2.x artifacts to their Maven 3.x counterparts.
>
> I am aware not all m2 artifacts have equivale
Hi everyone,
I am wondering what is general feeling about updating maven plugins from
depending on Maven 2.x artifacts to their Maven 3.x counterparts.
I am aware not all m2 artifacts have equivalents in m3 (i.e.
maven-project, maven-artifact-manager and few others). Things have moved
around
Hi,
(sorry, I can't speak english) I'm using a simple mojo that extends the
classpath for unit tests via
the surefire plugin and his parameter additionalClasspathElement.
The mojo works with maven 2.x but not with maven 3.x In maven 3.x the sure fire
plugin runs w
Sat, 2/19/11, nicolas de loof wrote:
From: nicolas de loof
Subject: Re: [PROPOSAL] Auto-Mirror Selection for Maven 3.x
To: "Maven Developers List"
Cc: "Stephen Connolly", "John
Casey"
Date: Saturday, February 19, 2011, 8:57 AM
I really like this feature sugge
ote:
>
> > From: nicolas de loof
> > Subject: Re: [PROPOSAL] Auto-Mirror Selection for Maven 3.x
> > To: "Maven Developers List"
> > Cc: "Stephen Connolly" , "John Casey" <
> jdca...@commonjava.org>
> > Date: Saturday, F
at least one enabled repo).
LieGrue,
strub
--- On Sat, 2/19/11, nicolas de loof wrote:
> From: nicolas de loof
> Subject: Re: [PROPOSAL] Auto-Mirror Selection for Maven 3.x
> To: "Maven Developers List"
> Cc: "Stephen Connolly" , "John Casey"
&
I really like this feature suggest, and it would be a must-have if also
backported to maven2 !
Having to maintain mirroring based on declared repositories ID is a pain,
especially when transitive dependencies pull multiple IDs for the same repo
URL. From your schema, it seems the routing rules are
Yep
On 18 February 2011 22:39, John Casey wrote:
> So you're saying it would work with existing releases of Maven, like 2.2.1?
> I'd be very interested to see that.
>
> -john
>
>
> On 2/18/11 5:23 PM, Stephen Connolly wrote:
>
>> I'll have a look at your branch, but I have an alternative proposa
So you're saying it would work with existing releases of Maven, like
2.2.1? I'd be very interested to see that.
-john
On 2/18/11 5:23 PM, Stephen Connolly wrote:
I'll have a look at your branch, but I have an alternative proposal that can
(I think) be made to work for any version of maven, per
I'll have a look at your branch, but I have an alternative proposal that can
(I think) be made to work for any version of maven, perhaps ivy too all by
just dropping a jar into the lib folder... I'll have to flesh it out to
confirm my theory. I'll be on two long flights at the start of march, so I
Sorry, that diagram is at:
https://github.com/jdcasey/maven-3/blob/auto-mirror/src/site/resources/images/RouteM%20Integration.png
Thanks,
-john
On 2/18/11 5:07 PM, John Casey wrote:
Hi all,
I wanted to submit a proposal that would help us improve the design of
mirroring support in Maven 3. T
Hi all,
I wanted to submit a proposal that would help us improve the design of
mirroring support in Maven 3. The approach I advocate would reduce the
amount of configuration needed to use local repository managers,
streamline environment setup for new users in a custom environment, and
provid
So the plan is that we're going to do a release of spice-inject as fast as we
can and then do the merge. So that will likely happen early next week. Until
then folks can pick things up from Benjamin's branch:
http://github.com/bentmann/maven-3
On Aug 19, 2010, at 4:20 AM, Tamás Cservenák wrote:
Cool!
+1 for merges!
Thanks,
~t~
2010/8/18 Arnaud Héritier
> Hi,
>
> I just rebuilt aether and maven3 and I have now : 14M/125M
> We are really near of 9M/125M we have in beta2
> Perfect !!!
>
> Let's go for a merge in trunk ??
>
> Arnaud
>
>
>>
>> There's been little to no feedback on beta-2 so I honestly don't think it
>> matters.
> feedback from Maven developers was good: since people complain only when it
> does not work, I suppose no feedback = it works as good as for Maven
> developers.
>
I agree, I consider also the no feedback
+1
On 18 August 2010 22:02, Jason van Zyl wrote:
>
> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
>
>> Hi,
>>
>> I just rebuilt aether and maven3 and I have now : 14M/125M
>> We are really near of 9M/125M we have in beta2
>> Perfect !!!
>>
>> Let's go for a merge in trunk ??
>>
>
>
Le jeudi 19 août 2010, Jochen Wiedmann a écrit :
> On Wed, Aug 18, 2010 at 11:18 PM, Hervé BOUTEMY
wrote:
> > I have only one concern with current maven-3 code in GitHub: it's not
> > compatible with maven-site-plugin 3.0-beta-1
>
> I think, that's a blocker for a new beta release, but not for a
Le mercredi 18 août 2010, Olivier Lamy a écrit :
> 2010/8/18 Benjamin Bentmann :
> > Olivier Lamy wrote:
> >> So maybe having a compatibility even if we are in a beta release
> >> process (benjamin ?)
> >
> > I don't feel motivated to maintain yet another layer of compat/bridge
> > code for the sa
On Wed, Aug 18, 2010 at 11:18 PM, Hervé BOUTEMY wrote:
> I have only one concern with current maven-3 code in GitHub: it's not
> compatible with maven-site-plugin 3.0-beta-1
I think, that's a blocker for a new beta release, but not for a merge, isn't it?
Jochen
--
I Am What I Am And That's Al
2010/8/18 Benjamin Bentmann :
> Olivier Lamy wrote:
>
>> So maybe having a compatibility even if we are in a beta release
>> process (benjamin ?)
>
> I don't feel motivated to maintain yet another layer of compat/bridge code
> for the sake of single beta plugin.
ok np for me.
>
>
> Benjamin
>
> -
Olivier Lamy wrote:
So maybe having a compatibility even if we are in a beta release
process (benjamin ?)
I don't feel motivated to maintain yet another layer of compat/bridge
code for the sake of single beta plugin.
Benjamin
---
2010/8/18 Hervé BOUTEMY :
> Le mercredi 18 août 2010, Olivier Lamy a écrit :
>> Herve : regarding site plugin there is a patch here (
>> https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eathe
>> r.patch ).
> yes, I know the patch (I studied it since our last discussion), but th
Le mercredi 18 août 2010, Olivier Lamy a écrit :
> Herve : regarding site plugin there is a patch here (
> https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eathe
> r.patch ).
yes, I know the patch (I studied it since our last discussion), but that
doesn't make the future maven
Well.. can we get that patch applied and a new release of the maven 3 site
plugin as well then.
manfred
PS: beta 2 works on all my projects..
> Hi,
> Let's go for merge ! (with last spice version 1.3.3-SNAPSHOT or
> released version to have a fix for SPICE-34).
>
> Herve : regarding site plugin
Hi,
Let's go for merge ! (with last spice version 1.3.3-SNAPSHOT or
released version to have a fix for SPICE-34).
Herve : regarding site plugin there is a patch here (
https://issues.sonatype.org/secure/attachment/23615/site-plugin-guice-eather.patch
).
2010/8/18 Hervé BOUTEMY :
> Le mercredi 18
Le mercredi 18 août 2010, Jason van Zyl a écrit :
> On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
> > Hi,
> >
> > I just rebuilt aether and maven3 and I have now : 14M/125M
> > We are really near of 9M/125M we have in beta2
> > Perfect !!!
> >
> > Let's go for a merge in trunk ??
>
>
On Aug 18, 2010, at 1:43 PM, Arnaud Héritier wrote:
> Hi,
>
> I just rebuilt aether and maven3 and I have now : 14M/125M
> We are really near of 9M/125M we have in beta2
> Perfect !!!
>
> Let's go for a merge in trunk ??
>
Yup, let's merge it all in and move forward.
> Arnaud
>
> On Aug
On Aug 18, 2010, at 10:47 PM, Hervé BOUTEMY wrote:
> Le mercredi 18 août 2010, Jason van Zyl a écrit :
>> On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:
>>> Le mercredi 18 août 2010, Arnaud Héritier a écrit :
It's always in GitHub or the merge started in trunk ?
>>>
>>> BTW, we have 3.
Le mercredi 18 août 2010, Jason van Zyl a écrit :
> On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:
> > Le mercredi 18 août 2010, Arnaud Héritier a écrit :
> >> It's always in GitHub or the merge started in trunk ?
> >
> > BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub wit
On Wed, Aug 18, 2010 at 10:10 PM, Jason van Zyl wrote:
> There's been little to no feedback on beta-2 so I honestly don't think it
> matters.
That's good news, isn't it? :-)
--
I Am What I Am And That's All What I Yam (Popeye)
---
Hi,
I just rebuilt aether and maven3 and I have now : 14M/125M
We are really near of 9M/125M we have in beta2
Perfect !!!
Let's go for a merge in trunk ??
Arnaud
On Aug 7, 2010, at 2:37 PM, Arnaud Héritier wrote:
> Results I had yesterday were :
>
> 3.0-benjamin (built yesterday) : 14
I'd love to offer more feedback on beta-2, but since it totally breaks our
builds it's a non-starter. Without reworking our entire build setup ( which
we're going to do anyway when we move to git ) M3 is effectively unusable
for my main $work project.
Which is a shame as all the new things look g
On Aug 18, 2010, at 12:59 PM, Hervé BOUTEMY wrote:
> Le mercredi 18 août 2010, Arnaud Héritier a écrit :
>> It's always in GitHub or the merge started in trunk ?
> BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with
> both
> Guice and Aether.
> What about merging Guice in s
Le mercredi 18 août 2010, Arnaud Héritier a écrit :
> It's always in GitHub or the merge started in trunk ?
BTW, we have 3.0-beta-2 released without Guice nor Aether and GitHub with both
Guice and Aether.
What about merging Guice in svn trunk, so we can test the 3 major steps: 3.0-
beta-2, +Guice,
Arnaud Héritier wrote:
It's always in GitHub or the merge started in trunk ?
It's still in github.
I'll try to build and test it this evening.
Cool, thanks!
Benjamin
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apach
It's always in GitHub or the merge started in trunk ?
I'll try to build and test it this evening.
Thx
On Aug 18, 2010, at 1:59 PM, Benjamin Bentmann wrote:
> Arnaud Héritier wrote:
>
>> 3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped
>> a lot)
>
> Should be fixed
Arnaud Héritier wrote:
3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a
lot)
Should be fixed now, would be cool if you could double-check when time
allows.
Benjamin
-
To unsubscribe, e-mail:
On Aug 8, 2010, at 11:34 PM, Brett Porter wrote:
>
> On 09/08/2010, at 12:39 PM, Mark Derricutt wrote:
>
>> Wouldn't this have the same problem with Apache based code? Doesn't the
>> Apache Contributor agreements say you assigned copyright over to Apache?
>
> No, it doesn't.
>
It is a grant
On 09/08/2010, at 12:39 PM, Mark Derricutt wrote:
> Wouldn't this have the same problem with Apache based code? Doesn't the
> Apache Contributor agreements say you assigned copyright over to Apache?
No, it doesn't.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
Wouldn't this have the same problem with Apache based code? Doesn't the
Apache Contributor agreements say you assigned copyright over to Apache?
As you say - out of scope for the list. I'll take my answer off-list (mmm,
sounds like a talk back radio caller!).
--
Pull me down under...
On Mon,
On Aug 8, 2010, at 9:17 PM, Brett Porter wrote:
>
> On 09/08/2010, at 10:55 AM, Jason van Zyl wrote:
>
So I refute this with an act by Kristian today which was to sign the
Sonatype CLA, sign up for the mailing list, asked for access to the wiki,
already has access and has
On 09/08/2010, at 10:55 AM, Jason van Zyl wrote:
>>>
>>> So I refute this with an act by Kristian today which was to sign the
>>> Sonatype CLA, sign up for the mailing list, asked for access to the wiki,
>>> already has access and has been working with Benjamin. You'll also notice
>>> he hasn
On Aug 8, 2010, at 8:18 PM, Brett Porter wrote:
>
> On 07/08/2010, at 9:47 PM, Jason van Zyl wrote:
>
>>
>> On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
>>
>>>
Unavoidable. We're not going to bring in everyone other dependency and any
developer worth their salt can figure
On 07/08/2010, at 9:47 PM, Jason van Zyl wrote:
>
> On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
>
>>
>>>
>>> Unavoidable. We're not going to bring in everyone other dependency and any
>>> developer worth their salt can figure out how to pull in sources for
>>> dependent projects. Aether
Results I had yesterday were :
3.0-benjamin (built yesterday) : 14M/2488M in 5:23.389s (It probably swapped a
lot)
3.0-beta-2 (downloaded few minutes ago) : 9M/125M built in 23.723s
2.2.1 : 67M/136M built in 30s
I only built one module :
http://svn.exoplatform.org/projects/ecms/trunk/packaging/
On Aug 7, 2010, at 7:26 AM, Brett Porter wrote:
>
> On 07/08/2010, at 12:44 AM, Arnaud Héritier wrote:
>
>> The advantage is to do what I did this morning in few minutes.
>> I found a OOME on Aether/Guice branch (reported to benjamin but not in MNG
>> because it's not yet integrated) and then
On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
>
>>
>> Unavoidable. We're not going to bring in everyone other dependency and any
>> developer worth their salt can figure out how to pull in sources for
>> dependent projects. Aether is all JIRA and Confluence it's not a big leap
>> for anyon
On 07/08/2010, at 12:44 AM, Arnaud Héritier wrote:
> The advantage is to do what I did this morning in few minutes.
> I found a OOME on Aether/Guice branch (reported to benjamin but not in MNG
> because it's not yet integrated) and then I validated it wasn't here in
> current trunk.
> The prob
On Aug 7, 2010, at 1:44 AM, Brett Porter wrote:
>
>
> And doesn't that show that you could have done the same thing with Aether? :)
>
Could happen with anything, it's only dependent on what people do.
>>> It is not an easily reversible step, and I want to ensure that anyone that
>>> wants
On 07/08/2010, at 1:23 PM, Jason van Zyl wrote:
>
> Ideally there should be no API leakage from Aether. As part of the plugin API
> we should provide access to whatever resolution functionality we feel is
> necessary to expose and hide Aether. Initially a few attempts are likely
> needed and
1 - 100 of 297 matches
Mail list logo
