Yep, we can flip most of the projects over to use a JDK 1.4 profile,
actually. Will do that after the next software upgrade.
- Brett
On 22/08/2007, at 4:02 PM, Hervé BOUTEMY wrote:
+1
but it seems that actual Continuum server is compiling with jdk 1.5
instead of
1.4
The following build sh
+1
but it seems that actual Continuum server is compiling with jdk 1.5 instead of
1.4
The following build should have failed since the commit makes use of
String.contains(String) API in CheckDependencySnapshotsPhase class
see
http://maven.zones.apache.org/continuum/buildResult.action?buildId=164
Jason,
> So why can't it all be in one repository? You have people who buy
> your products with a non-source license and you give them access to
> binaries from a Maven repository instead of an installer? Or you have
> updaters that use a Maven repository so you only need the binaries
> for
On 22/08/2007, at 1:10 AM, Jason van Zyl wrote:
We're going to end up with two code lines to maintain but sharing
maven-artifact (and possibly the container) would make it much easier.
I'm really not in favour of this. Isn't the investment better placed
in working towards a shippable 2.1 wi
Thanks again everyone for the warm welcome :)
-Deng
Jesse McConnell wrote:
Welcome Deng! :)
On 8/21/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
Welcome Deng !
cheers
Arnaud
On 21/08/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Welcome and congrats!
-Original Message-
Fr
Raphaël has access now, so as I understand it the steps are as follows:
1) create a tarball of the code, and checksum
2) check that it in to the sandbox for historical purposes
3) expand in the sandbox, remove the tarball
4) file IP clearance paperwork (already started, just needs to be
moved t
Just tallying this up fully from the thread before.
+1: Jesse, Brett, Jason, Arnaud, Stephane, Andy, John, Brian
Everyone welcome Raphaël :)
Cheers,
Brett
On 29/06/2007, at 4:28 PM, Jason van Zyl wrote:
Hi,
After a fews weeks of sorting out some niggly details the new code
new by default
On 21 Aug 07, at 5:43 PM 21 Aug 07, James William Dumay wrote:
Sorry if I'm missing something but why they can't just publish
everything to their private repo and just mirror things
they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more in
> Sorry if I'm missing something but why they can't just publish everything to
> their private repo and just mirror things
> they want share to the public repository afterwards?
Sure, that could be done, however, this is yet more infrastructure that
needs to be written and maintained in the buil
On 21 Aug 07, at 5:01 PM 21 Aug 07, Brian E. Fox wrote:
I'm not fan of featuritis, but it sounded like a valid use case, and
since it gives the same net effect and doesn't affect any backwards
compatibility I thought it was worth going ahead with.
Same here. There is already a concept of atta
On 21 Aug 07, at 4:58 PM 21 Aug 07, Brett Porter wrote:
On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
(I'm resending this mail from another account because previous one
seems to be stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). T
>I'm not fan of featuritis, but it sounded like a valid use case, and
>since it gives the same net effect and doesn't affect any backwards
>compatibility I thought it was worth going ahead with.
Same here. There is already a concept of attached artifacts and there is
a parameter for an alterna
On 22/08/2007, at 8:17 AM, Grzegorz Kossakowski wrote:
(I'm resending this mail from another account because previous one
seems to be stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). They ship their
jars
and javadocs to users who want to wr
+1, deploying to snapshot repo would be good too.
Andy
On 21 Aug 2007, at 03:38, Brett Porter wrote:
Hi,
Continuum has been running on the zone for a while. Some people
have been watching the results vigilantly, but others have probably
missed them, or presumed them erroneous.
There ar
I'm trying to get surefire to run some unit tests (and integration
tests) for an ear project of mine, but am running into lots of
problems. I realize that the ear lifecycle doesn't contain any of the
regular compile, resource or surefire goals, so most of this is just
trial and error. Here's
(I'm resending this mail from another account because previous one seems to be
stuck in moderation queue)
Brian E. Fox pisze:
I believe this came from Atlassian. (I386 on irc). They ship their jars
and javadocs to users who want to write plugins etc, but the sources
stay internal (or to paying
I would recommend changing your poms to avoid the situation where expansion on
install/deploy is required for things to work.
By containing variables I assume you mean expression expantion. So all the
properties should be expanded? I think that makes some sense but it affects
the ability to com
I believe this came from Atlassian. (I386 on irc). They ship their jars
and javadocs to users who want to write plugins etc, but the sources
stay internal (or to paying customers I think).
-Original Message-
From: Paul Gier [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 3:02 PM
+1
and it'd be great if it deploys snapshots too :D
On 8/21/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Continuum has been running on the zone for a while. Some people have
> been watching the results vigilantly, but others have probably missed
> them, or presumed them erroneous.
>
> The
+1, definitely.
-john
On Aug 20, 2007, at 10:38 PM, Brett Porter wrote:
Hi,
Continuum has been running on the zone for a while. Some people
have been watching the results vigilantly, but others have probably
missed them, or presumed them erroneous.
There are builds that are failing beca
+1 of course
Brett Porter wrote:
Hi,
Continuum has been running on the zone for a while. Some people have
been watching the results vigilantly, but others have probably missed
them, or presumed them erroneous.
There are builds that are failing because of errors that haven't been
caught (an
The use case seems to be for non open source projects. They want to distribute
their binaries and jars publicly, but keep the sources internal. Not that I
agree with this practice, but I'm guessing that is one reason for these requests.
Eric Redmond wrote:
On 8/21/07, Stefano Bagnara <[EMAIL
This appears to be working with 2.0.7 and 2.1.x. I'm using the
following:
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
org.apach
Why DependencyNode.getDepth was deprecated? it's still useful
On 6/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: markh
> Date: Thu Jun 21 08:53:42 2007
> New Revision: 549521
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=549521
> Log:
> Major changes to maven-dependency-tree:
On 8/21/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
> Jason van Zyl ha scritto:
> > I'm not sure this is something we want to encourage before the patches
> > are applied. Keeping the sources and javadoc JARs together seems like
> > a good thing to do. The sources and javadocs located in diffe
Jason van Zyl ha scritto:
>
> If you are using the IDE integration how is it going to know where to
> find the sources and javadocs for debugging. That's one simple case.
> By adding a tweak to make the deployment diverge from the standard you
> potentially ruin the integration with other tooling.
On 21 Aug 07, at 4:43 AM 21 Aug 07, Mark Hobson wrote:
Just catching up on emails - here's the related issues:
http://jira.codehaus.org/browse/MNG-2972
http://jira.codehaus.org/browse/MNG-2163
Does anyone see any problem resolving these? I think we have to be
able to allow overriding of d
On 21 Aug 07, at 9:43 AM 21 Aug 07, Stefano Bagnara wrote:
Jason van Zyl ha scritto:
I'm not sure this is something we want to encourage before the
patches
are applied. Keeping the sources and javadoc JARs together seems like
a good thing to do. The sources and javadocs located in different
Jason van Zyl ha scritto:
> I'm not sure this is something we want to encourage before the patches
> are applied. Keeping the sources and javadoc JARs together seems like
> a good thing to do. The sources and javadocs located in different
> locations doesn't seem to make much sense to me and there'
I'm not sure this is something we want to encourage before the
patches are applied. Keeping the sources and javadoc JARs together
seems like a good thing to do. The sources and javadocs located in
different locations doesn't seem to make much sense to me and there's
no real explanation with
If this is done (not sure I'm convinced) I think this also needs to be handled
in a way for Install also. Otherwise the pom in your local repo won't match
what ultimately gets deployed. This could cause lots of headaches.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTE
Mark,
If you are going to be around today I was going to apply some patches
and do some fixes but I wanted to get some feedback about attempting
to use the same separate code now in maven-artifact. It would be far
better to use the same code for both 2.0.x and 2.1.x and I don't
believe th
On 21 Aug 07, at 8:39 AM 21 Aug 07, Stephane Nicoll wrote:
Hey,
There's a .rip directory on repo1 since we staged maven-ear-plugin
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-ear-
plugin/2.3.1/2.3.1.rip/
It's not in the sync dir. Can anyone fix this?
The sync must have h
As long as we're free to evaluate other tools. Since we've never
actually done any comparison I don't want this to be cast in stone or
be the only tool we use. In other words I don't want this mandated.
I'm happy that it is setup, provided I can use Hudons or something
else. Continuum has n
Welcome Deng! :)
On 8/21/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
>
> Welcome Deng !
>
> cheers
>
> Arnaud
>
> On 21/08/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > Welcome and congrats!
> >
> > -Original Message-
> > From: Wendy Smoak [mailto:[EMAIL PROTECTED]
> > Sent: Monday, A
Hey,
There's a .rip directory on repo1 since we staged maven-ear-plugin
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-ear-plugin/2.3.1/2.3.1.rip/
It's not in the sync dir. Can anyone fix this?
Thx,
Stéphane
--
Large Systems Suck: This rule is 100% transitive. If you build one,
y
Just catching up on emails - here's the related issues:
http://jira.codehaus.org/browse/MNG-2972
http://jira.codehaus.org/browse/MNG-2163
Mark
On 15/08/07, Paul Gier <[EMAIL PROTECTED]> wrote:
> Brian E. Fox wrote:
> >> But that is only for the transitive plugin dependencies right? What
> > abo
Hi,
2007/8/20, Brett Porter <[EMAIL PROTECTED]>:
> Hi,
>
> Continuum has been running on the zone for a while. Some people have
> been watching the results vigilantly, but others have probably missed
> them, or presumed them erroneous.
>
> There are builds that are failing because of errors that h
Hi All,
When using Maven in my job, I'm encountering a problem of deployed POM which
still contain variables.
I would like to deploy POM whith the valued variables.
I've looked at the deploy plugin source code, and I've understand that the
deployed POM was
the file POM on the disk.
But, it could
If it gets committed to again, yeah, you should be able to add it to
the existing instance without any problems under it's own group.
On 21/08/2007, at 5:41 PM, Lukas Theussl wrote:
Definetely +1. I wouldn't have thought that we need a vote for this...
As a sidenote: Arnaud once had a contin
Definetely +1. I wouldn't have thought that we need a vote for this...
As a sidenote: Arnaud once had a continuum instance set up for maven1,
which I don't see anymore. Not that I expect much development anymore
but just in case, could that be added to the project groups on zones?
Thanks,
-Lu
Sounds good.
+1,
Stéphane
On 8/21/07, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Continuum has been running on the zone for a while. Some people have
> been watching the results vigilantly, but others have probably missed
> them, or presumed them erroneous.
>
> There are builds that are fa
42 matches
Mail list logo
