On 11/8/06, Brett Porter <[EMAIL PROTECTED]> wrote:
On 08/11/2006, at 5:10 PM, Nathan Beyer wrote:
> On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>> Yikes, I'm getting forgetful in my old age. I thought the section on
>> that had been omitted from the final version of the book until it wa
On 08/11/2006, at 5:10 PM, Nathan Beyer wrote:
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Yikes, I'm getting forgetful in my old age. I thought the section on
that had been omitted from the final version of the book until it was
implemented.
Since we are no longer allowing changes to
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Yikes, I'm getting forgetful in my old age. I thought the section on
that had been omitted from the final version of the book until it was
implemented.
Since we are no longer allowing changes to metadata in the repository
(unless it is an extre
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
Since we still have the problem of circular dependencies in there
(plugins use the javadoc and other reports, so it can't figure out
the right order to build), you can't use the parent to run from, but
you can probably do:
mvn -r '*/pom.xml' si
I meant extending the notion that every Project or ProjectGroup added to
a Schedule also has an order attached to it which may be user assigned
or default.
Rahul Thakur wrote:
How about extending the notion of Schedule and allow the user to
re-order builds in a schedule? In absence of any o
How about extending the notion of Schedule and allow the user to
re-order builds in a schedule? In absence of any order, default to the
order the Projects/ProjectGroups were added to the schedule.
Rahul
Jesse McConnell wrote:
I was reading through the DefaultContinuum.buildProjects( Schedu
Committers,
1) I've added a patch for CONTINUUM-997 to work with the patch on
MNG-2626.
2) Unfortunately, a core part of the patch for MNG-2626 (the line
that activates it) was left out of the patch in there. I've added that.
Jason, you were looking at this test case last week, if you have
My first pick is the one on the lower left. I also like the one on the
lower right, so I guess that's my second pick :-)
Brett Porter wrote:
Hi,
There seemed to be no major objections to the logos presented, so
I'll turn this into a formal vote.
Please vote [1] for the one you would like
I think you want global ordering. Grouping should just be a display/
management technique, not anything that changes how projects are
handled.
However, this needs to be reviewed as a whole (which I think Emmanuel
is doing), such that builds can be triggered when their dependencies
change w
Yikes, I'm getting forgetful in my old age. I thought the section on
that had been omitted from the final version of the book until it was
implemented.
Since we are no longer allowing changes to metadata in the repository
(unless it is an extreme case), then repeatability shouldn't be a
p
Hi,
There seemed to be no major objections to the logos presented, so
I'll turn this into a formal vote.
Please vote [1] for the one you would like and [2] for your second
preference, if you have one, and so on.
Ideally, there will be a clear majority of first preferences. The
lowest sc
On 08/11/2006, at 11:27 AM, Wendy Smoak wrote:
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I think the addition of new documentation outweighs the problems
we'll see from snapshot features, but we should mark them up as we
[see] them.
I agree. So, who would like to do do the honors
One thing that perhaps Emmanuel could explain a bit more is the third
comment there. In our conversation on this he said that he thinks
that the cycles are cropping up all the time, and if thats the case
then we are building a lot of unordered builds which would account for
some of the strange re
On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
I think the addition of new documentation outweighs the problems
we'll see from snapshot features, but we should mark them up as we
[see] them.
I agree. So, who would like to do do the honors and publish the
updated plugin sites?
I'm happy
MNG for now - thanks!
On 08/11/2006, at 5:57 AM, Mark Hobson wrote:
On 25/09/06, Brett Porter <[EMAIL PROTECTED]> wrote:
If you need the structure, yes. It would be good to factor out into a
common component - currently we use this from archiva via the project
info reports plugin.
I've got a
Thanks, that's what I thought.
On 08/11/2006, at 5:16 AM, Dennis Lundberg wrote:
Brett Porter wrote:
Hi,
I wasn't thinking when I changed the inheritence on the plugin
sites, as it is designed to adjust the path when you inherit
according to the URLs in the POM (which enables you inheritin
Why doesn't continuum-model produce the unenhanced JAR, and attach an
enhanced JAR as a second artifact with a classifier?
- Brett
On 08/11/2006, at 9:11 AM, Carlos Sanchez wrote:
it's gonna be tricky because continuum-jpox would include the classes
of continuum-model, so it has to exclude t
I was reading through the DefaultContinuum.buildProjects( Schedule id
) method and after discussing some things with Emmanuel...I think we
have a problem here. When I went through and refactored things to
support a more Project Group centric setup with continuum I changed
this method a bit.
Orig
it's gonna be tricky because continuum-jpox would include the classes
of continuum-model, so it has to exclude that dependency.
On 11/7/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
I'm agree, but I'm not sure it will be used elsewhere that rpc-client
Carlos Sanchez a écrit :
> ok, then we'll
It is...
Mvgr,
Martin
Emmanuel Venisse wrote:
I'm agree, but I'm not sure it will be used elsewhere that rpc-client
Carlos Sanchez a écrit :
ok, then we'll probably need continuum-model and continuum-model-jpox,
agree ?
On 11/7/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
Carlos,
I'm n
I'm agree, but I'm not sure it will be used elsewhere that rpc-client
Carlos Sanchez a écrit :
ok, then we'll probably need continuum-model and continuum-model-jpox,
agree ?
On 11/7/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
Carlos,
I'm not sure it's correct. If you use continuum-model,
(I asked this once before, but the thread got hijacked into other matters, so
let's try this again...)
Will the next release of the Release plugin include the "generateReleasePoms"
functionality, e.g. the creation of a POM with resolved versions? If you were
to believe Better Builds with Maven
ok, then we'll probably need continuum-model and continuum-model-jpox, agree ?
On 11/7/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
Carlos,
I'm not sure it's correct. If you use continuum-model, you use java classes
enhanced by jpox
Emmanuel
[EMAIL PROTECTED] a écrit :
> Author: carlos
>
Jesse,
Is it possible to sort projects in the group instead of build them in the wrong order? I think it
would be a better solution.
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: jmcconnell
Date: Tue Nov 7 11:35:42 2006
New Revision: 472221
URL: http://svn.apache.org/viewvc?view=rev&rev=472
Carlos,
I'm not sure it's correct. If you use continuum-model, you use java classes
enhanced by jpox
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: carlos
Date: Mon Nov 6 18:12:00 2006
New Revision: 471967
URL: http://svn.apache.org/viewvc?view=rev&rev=471967
Log:
Don't rebuild model and depe
This maybe moot but this reminds me of something that bothered me a while
back:
The problem here is the lack of project identity (group id, artifact id,
version) support in sites. A site is simply a view upon a project and yet
there is no way for us to reflect which version that site was generated
On 25/09/06, Brett Porter <[EMAIL PROTECTED]> wrote:
If you need the structure, yes. It would be good to factor out into a
common component - currently we use this from archiva via the project
info reports plugin.
I've got around to factoring the dependency tree assembling code from
maven-proje
Brett Porter wrote:
Hi,
I wasn't thinking when I changed the inheritence on the plugin sites, as
it is designed to adjust the path when you inherit according to the URLs
in the POM (which enables you inheriting navigation to a particular
document, not templating the specification of a particu
Take a look at the end of
http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
We use rsync over ssh.
On 11/7/06, Geoffrey De Smet <[EMAIL PROTECTED]> wrote:
Carlos,
When spring-richclient released 0.2.1 I tried to make an upload bundle,
but there's an issue for that for multiprojects.
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Also, maybe the @since tags should be documented as well in [1]?
Yes, but isn't this also included in the Maven site somewhere?
hhmm..never seen it in maven2 site. but i've seen some goals
documentation in maven-1.x with the 'since' colu
On ibiblio, maven1 plugins are packaged with ".plugin" extension. This
was not the case some weeks ago.
Maven-on-plugin creates .jar. What is the expected extension for maven1
plugins ?
Nico.
This message contains information that may be privileged or confidential and is
the property of t
Wendy Smoak wrote:
On 11/6/06, Brian E. Fox <[EMAIL PROTECTED]> wrote:
Does anyone see a drawback to doing this for maven itself? I'd volunteer
to help make the changes but I don't think I have karma to touch maven
core where the pom seems to live.
The drawback is that it's another jar that
Done.
Vincent
2006/11/6, Brett Porter <[EMAIL PROTECTED]>:
src/site/odt?
One day, we'll be able to convert it automatically and can remove the
target (though currently that requires having Oo2 installed, and
firing it up during the build, so I wouldn't inflict that on us just
yet :)
- Brett
No, using a spec of 1.0 should give you 1.0.
It was an implementation decision to give best compatibility with the
use-nearest conflict resolution and the existing POMs (if all such
versions were treated as "must be 1.0", then most transitive deps
would fail because most dependencies declar
On 07/11/2006, at 3:53 PM, Wendy Smoak wrote:
On http://maven.apache.org/wagon/, many of the menu links are broken.
They're relative to /wagon rather than one level up where they belong.
Brett, is this related to your recent navigation inheritance changes?
No, it hasn't been published since
Carlos,
When spring-richclient released 0.2.1 I tried to make an upload bundle,
but there's an issue for that for multiprojects.
So I was wondering if you can't just sync our repo? :)
http://spring-rich-c.sourceforge.net/maven2repository/org/springframework/richclient/
--
With kind regards,
G
On 11/6/06, Brett Porter <[EMAIL PROTECTED]> wrote:
That's the defined behaviour.
Ok, so using a spec of '1.0' is wrong? Should VersionRange not
complain then? I don't understand why '1.0' and '[1.0]' are not the
same.
-
To un
37 matches
Mail list logo
