Hi,
we currently have the WhitespaceAround module active, which per
default looks for Tokens and (LT and GT). Now we have a problem
with GenericTypes, e.g lines with ListItem will cause a checkstyle
warning.
Of course one could simply remove the tokens GT and LT from the
+1 for me in that case.
We will need to state clearly in the release notes that now the .scm
subdirectory of the user's home directory will be used!
regards,
Wim
2006/12/6, Emmanuel Venisse [EMAIL PROTECTED]:
SCM-190 and SCM-199. They're very simple patches.
Emmanuel
Wim Deblauwe a écrit
After some thoughts, I think it isn't good, a blank part is better. I'll revert
it.
Emmanuel
Brett Porter a écrit :
I left this out on purpose. Is it really a good idea?
- Brett
On 06/12/2006, at 6:18 AM, [EMAIL PROTECTED] wrote:
Author: evenisse
Date: Tue Dec 5 11:18:34 2006
New
I'd like to use the same css for all our web parts but I don't know if I'll
found the time to do it.
If we move to the standard xhtml template, will we keep the actual continuum
page style?
I think it would be good to create a shared module that include the header,
footer, breadcrumb and css,
We can clean them. I don't think session-models is used.
Emmanuel
Brett Porter a écrit :
anyone?
On 01/12/2006, at 11:29 AM, Brett Porter wrote:
I see a couple of models in continuum-webapp, which seem to be
partially used. Does anyone know if session-models is used any more?
What about
SCM-190 and SCM-199. They're very simple patches.
Emmanuel
Wim Deblauwe a écrit :
Hi Emmanuel,
I don't have much time to test ClearCase. Also, I'm still not using it
myself. We are still stuck with Maven 1 for the moment.
Could you give me list of changes to the ClearCase provider since
Simone Gianni schrieb:
Steve Loughran wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some person who would
Not really - I'm with Dan here, if we are working to a beta-4 release
surely it should be 1.0-beta-4-SNAPSHOT.
That way there is no confusion as to what version to release. Then when
1.0 is ready it can be dropped up to the 1.0 level.
Is this not the behavior documented in BBwM?
Andy
Yes, it's just a pain to change it only to change it back again when
a release is imminent.
- Brett
On 06/12/2006, at 8:59 PM, Andrew Williams wrote:
Not really - I'm with Dan here, if we are working to a beta-4
release surely it should be 1.0-beta-4-SNAPSHOT.
That way there is no
fair point - if you are imminently making the release I suppose it makes
sense ;)
Andy
Brett Porter wrote:
Yes, it's just a pain to change it only to change it back again when a
release is imminent.
- Brett
On 06/12/2006, at 8:59 PM, Andrew Williams wrote:
Not really - I'm with Dan here,
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 17:43:29:
As I said before, I've had very good results with a build system in
which
you can specify arbitrary phases and say this phase depends on
that one.
And how much luck have you had showing that system to other people?
And
Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52:
The weakness is that someone, somewhere, has to lay down what those
states are. And what works for simple
ready-to-compile-compiled-packaged-tested-published lifecycle gets
complex if you have to do silly things like throw
Ralph Goers wrote:
Steve Loughran wrote:
Ralph Goers wrote:
Steve Loughran wrote:
Simone Gianni wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases
[EMAIL PROTECTED] wrote:
Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52:
The weakness is that someone, somewhere, has to lay down what those
states are. And what works for simple
ready-to-compile-compiled-packaged-tested-published lifecycle gets
complex if you have to do
A build tool should make the obvious things simple but it should not
prevent to solve corner cases. The current maven build system just cannot
cope with running mvn deploy for a part of the project so you can run
your tests in another.
The question is not if it's a stupid thing to do, the
Jim Crossley wrote:
Apologies if this is too off-topic, but...
On Tue, 2006-12-05 at 17:28 +, Steve Loughran wrote:
Because that's the kind of thing we can automate and lock down under
SCM. That lets us create a blank VMWare or Xen disk image, have it run a
PXE preboot to get the base
On 6 Dec 06, at 1:05 AM 6 Dec 06, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Tue Dec 5 22:05:43 2006
New Revision: 482918
URL: http://svn.apache.org/viewvc?view=revrev=482918
Log:
Working on a generator for junit wrappers for integration-test builds.
Added:
Fabian Christ wrote:
Simone Gianni schrieb:
Steve Loughran wrote:
The thing to remember about WAR files is that they are a packaging
format that is intended to make it easy to deploy web apps. Not
distribute, but deploy. The old WAR/EAR use cases always had the
'assembler' who would be some
I think I added a couple of models since there had been precendent in
there being other models in use and as a way to present data into the
extreme components which needed objects presented in a certain fashion
if we can do away with them without issues then I am for that :)
jesse
On 12/6/06,
I am thinking about an archetype, but I wanted to play around a little more
with using this as sort of generating IDE bindings to the existing
integration tests...perhaps an archetype would be better, I don't know.
IMO, an archetype means moving primarily to junit-triggered integration
tests,
I have spoken with a few committers over IRC, ApacheCon etc about this
so here it comes. Some of us would like to include maven into Fedora
distributions. There are two components to this, one technical and the
other process similar to the Apache incubator process in that you need
a sponsor,
On 6 Dec 06, at 11:38 AM 6 Dec 06, Carl Trieloff wrote:
I have spoken with a few committers over IRC, ApacheCon etc about
this so here it comes. Some of us would like to include maven into
Fedora distributions. There are two components to this, one
technical and the other process similar
The point is to try use maven to build Java pieces in OS distros which
should be a good thing.
Carl.
Jason van Zyl wrote:
On 6 Dec 06, at 11:38 AM 6 Dec 06, Carl Trieloff wrote:
I have spoken with a few committers over IRC, ApacheCon etc about
this so here it comes. Some of us would
I personally have never trusted any linux based package manager to
install any java software, maybe that's just me being paranoid..
That being said, I have observed many users referencing having
installed ant via package manager on linux distro in the dojo
users list. As long as the maven devs
On 6 Dec 06, at 12:00 PM 6 Dec 06, Carl Trieloff wrote:
The point is to try use maven to build Java pieces in OS distros
which should be a good thing.
I guess some might, but I've have never used an RPM package for a
Java library and I don't know anyone who has. You might package up a
Right. I forgot to mention in my last email that in a good 98% of the
cases the only reason we've ever found out that dojo users install ant
via a package manager is because they are having conflicting library
classpath problems. (related to rhino)
On 12/6/06, Jason van Zyl [EMAIL PROTECTED]
Personally, I'm finding it a little hard to divorce the maven-developer in
me here, and see it from an average Joe perspective...
I think it could be great to have the ability to install Maven from yum,
apt-get, port, emerge, etc. I think many users who are more interested in
developing and
I tend to agree with Jason van Zyl's comments... though I can
certainly see the ease of `yum install maven2` or something to get
everything up and going for the novice. Though that brings up a
question... which Java will that use? The default version of Java
that comes with FC5 is not
On Wed, 2006-12-06 at 11:57 -0500, Jason van Zyl wrote:
On 6 Dec 06, at 11:38 AM 6 Dec 06, Carl Trieloff wrote:
I have spoken with a few committers over IRC, ApacheCon etc about
this so here it comes. Some of us would like to include maven into
Fedora distributions. There are two
Thanks for clearing that up.
--
Dennis Lundberg
Emmanuel Venisse wrote:
the release will be beta-4, but the version is maven-scm poms is
actually 1.0-SNAPSHOT and I won't change them before the release. When
I'll release, I'll set the version to beta-4 and not 1.0.
The next version will be
I think it might be smarter to start from first principles on this stuff,
and attempt to create a toolset that would allow us to make RH/Debian/etc.
compatible packages from all maven builds, including Maven itself an Maven's
dependencies.
FWIW, I've looked at some of the patches you posted, and
John Casey wrote:
Let's start with: What are the requirements?
Regards,
John
yes that is good - I would not see the patches set as something to
commit as is but a prototype to see if it could
be done. we now think it can - and would do it in a way that works for
maven.
The key parts
WRT `mvn -o`, what's missing in the offline behavior there? Maybe we need to
consider making that more complete.
WRT packaging guidelines, are you talking about this:
http://fedora.redhat.com/docs/developers-guide/
or, is there a pertinent sub-section?
Thanks,
John
On 12/6/06, Carl Trieloff
On Wednesday 06 December 2006 14:08, Deepak Bhole wrote:
1. Who is going to maintain this? It seems rather complicated when we
have something that works pretty easily.
The patch's goals are twofold.
1: Ensure full offline mode (the -o switch still allows maven to try and
check for
2: Ensure that projects can build against a single version of a
dependency, rather than multiple.
This bothers me the most. If my project's pom.xml says I depend on foo
version 1.1.3, it better be built and installed with foo version 1.1.3,
not foo version 1.2 or foo version 1.1.5 of foo
Daniel Kulp wrote:
2: Ensure that projects can build against a single version of a
dependency, rather than multiple.
This bothers me the most. If my project's pom.xml says I depend on foo
version 1.1.3, it better be built and installed with foo version 1.1.3,
not foo version 1.2
They were all installed via rpm.
Seems to me that the multiple versions of a resource can be done with rpm.
Correct.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
John Casey wrote:
2: Ensure that projects can build against a single version of a
dependency, rather than multiple.
This bothers me the most. If my project's pom.xml says I depend on foo
version 1.1.3, it better be built and installed with foo version
1.1.3,
not foo version 1.2 or foo
All of this makes sense, until you consider that the user might start using
the Fedora-provided version of Maven for his own software builds. Then you
have a possibility of letting him produce a very messy build that doesn't
use artifact versions. If the possibility is there, it will be [ab]used.
John Casey wrote:
All of this makes sense, until you consider that the user might start using
the Fedora-provided version of Maven for his own software builds. Then you
have a possibility of letting him produce a very messy build that doesn't
use artifact versions. If the possibility is there,
Rafael Schloming wrote:
John Casey wrote:
All of this makes sense, until you consider that the user might start
using
the Fedora-provided version of Maven for his own software builds. Then
you
have a possibility of letting him produce a very messy build that doesn't
use artifact versions.
Can a dev comment on http://jira.codehaus.org/browse/MANTRUN-51 and/or
http://jira.codehaus.org/browse/MANTRUN-63 since I'm pretty sure their one
and the same? This is such an issue to work around that previously I got
around it by breaking my command invocation into 2 separate mvn invocations
the maven.new branch which contained the work to get maven up to the
latest and greatest plexus container and classworlds has been
branched to trunk.
The tests all pass and bootstrapping works here, please bug Jason or
I if there appears to be any problems with this substantial change.
running mvn install, I get the following error as below, but as you
can see there is not enough information telling me why this is a
problem. I tried hacking the pom so that
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-utils/artifactId
version1.1/version
DefaultPluginManager is the place to look. You are looking for the
creation of a child plexus container, and jar resources being added
to that.
On 07/12/2006, at 10:20 AM, Wendell Beckwith wrote:
Can a dev comment on http://jira.codehaus.org/browse/MANTRUN-51 and/or
I generally agree with what John has said in the thread so far. I
think this is a good thing: a nice out of the box installation, but
you can still roll your own if needed. I think it's important that we
break this down into the requirements like these listed below and
work through them,
Thanks Brett. I'll try digging through it later tonight.
Wb
On 12/6/06, Brett Porter [EMAIL PROTECTED] wrote:
DefaultPluginManager is the place to look. You are looking for the
creation of a child plexus container, and jar resources being added
to that.
On 07/12/2006, at 10:20 AM, Wendell
On 6 Dec 06, at 8:18 PM 6 Dec 06, Brett Porter wrote:
DefaultPluginManager is the place to look. You are looking for the
creation of a child plexus container, and jar resources being added
to that.
On the code we're about to merge into trunk the container creation is
now gone. It's the
Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (35 issues)
Subscriber: mavendevlist
Key Summary
MEV-459 Velocity should not depend on Velocity-dep
http://jira.codehaus.org/browse/MEV-459
MEV-469 jaxb-api available with two different groupIds
Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (12 issues)
Subscriber: mavendevlist
Key Summary
MAVENUPLOAD-1243JCommon 1.0.6
http://jira.codehaus.org/browse/MAVENUPLOAD-1243
MAVENUPLOAD-1149Upload jboss-seam-ui-1.0.1.jar
Cool. What's next?
On 07/12/2006, at 11:51 AM, Andrew Williams wrote:
the maven.new branch which contained the work to get maven up to
the latest and greatest plexus container and classworlds has been
branched to trunk.
The tests all pass and bootstrapping works here, please bug Jason
or
I might add that these artifacts are in my local repository.
Trawling through poms now to see if I can find differing versions.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 6 Dec 06, at 8:16 PM 6 Dec 06, Brett Porter wrote:
I generally agree with what John has said in the thread so far. I
think this is a good thing: a nice out of the box installation
Define nice? If it's an installation that is different then something
standard that users typically get
On 6 Dec 06, at 3:02 PM 6 Dec 06, Carl Trieloff wrote:
John Casey wrote:
Let's start with: What are the requirements?
Regards,
John
yes that is good - I would not see the patches set as something to
commit as is but a prototype to see if it could
be done. we now think it can - and
For anyone using IDEA and you want to lend a hand updating license
headers the copyright plugin in IDEA allows you to import settings
from another .ipr file so you can use this one and it should give you
the same settings that I've been using for plugins I've been
preparing to release:
On 07/12/2006, at 2:25 PM, Jason van Zyl wrote:
On 6 Dec 06, at 8:16 PM 6 Dec 06, Brett Porter wrote:
I generally agree with what John has said in the thread so far. I
think this is a good thing: a nice out of the box installation
Define nice? If it's an installation that is different
I'm having trouble building Continuum with Maven 2.0.5-SNAPSHOT.
I get a test error in continuum-release, and it seems to be due to
Maven selecting the 2.0 version of maven-artifact instead of the 2.0.4
version.
If I build with Maven 2.0.4, it works fine.
If I add a dependency on
ya, if you look through her debug output there is a big chunk where
all the 2.0.4 deps are getting reverted to 2.0 just like in the error
message below.
it effected a number of the dependencies
[DEBUG] Retrieving parent-POM: org.apache.maven:maven::2.0.4 for
project:
Jason van Zyl wrote:
I just don't see the value in this for Maven users. Carl what value do
you see as a real benefit to Maven users who work on Redhat?
Jason.
My 2 cents.
I primarily use Linux to develop Java. Here are the steps I use when
installing RHEL 4.0 WS.
1. Install OS.
2.
Isn't there a way we can do this with an action message rather than
creating our own custom strings every time?
- Brett
On 07/12/2006, at 3:08 PM, [EMAIL PROTECTED] wrote:
Author: oching
Date: Wed Dec 6 20:08:03 2006
New Revision: 483341
URL:
On 12/7/06, Barrie Treloar [EMAIL PROTECTED] wrote:
I might add that these artifacts are in my local repository.
Trawling through poms now to see if I can find differing versions.
If I comment out
org.apache.maven.shared.maven-plugin-testing-tools:1.0-SNAPSHOT from
the pom file I get past
Hello Sir,
i have a basic dought what is -f, -D which is used maven -f pom.xml
clean install,
and how many type of these do we have. waiting for your reply.
Thanks
Aditya
62 matches
Mail list logo
