I would have expected the JAR archiver to be single use (IIRC,
perlookup instantiation-strategy instead of the default). Is it
possible this is a regression in a recent version of the archiver?
- Brett
On 11/02/2008, at 10:46 PM, nicolas de loof wrote:
Hello,
I need to build multiple
I didn't know this, so I imagine others might not. The string #x0; is
invalid XML. The character is simply not allowed in XML in any
representation. XML 1.0 standard blocks most of the characters under x20,
allowing only x9 xA and xD. XML 1.1 allows x1-x20, but still blocks x0.
I agree. It is imperative that we keep a clear succinct list of phases
for the different builds. Allowing ad hoc additions will make
understanding a POM less portable.
I also like the idea of doing away with the pre and post phases (but not
the functionality). I suggest abstracting out the
Hi,
More comments inside...
2008/2/11, Dennis Lundberg [EMAIL PROTECTED]:
Alexander Sack wrote:
Hey Vincent:
No problem. I would love to. I have a really really stupid question.
What I've done is:
1) Checked out the 2.0.x trunk
This is not necessary, you can use a regular Maven
Hi John,
That looks very interesting!
BTW, what is 'Just-in-time lifecycle discovery and configuration'?
Rahul
John Casey wrote:
Hi all,
I've written up the new features present in the refactored lifecycle
support for 2.1, if anyone is interested in reading it. I'd like to
hear what you
On 12/02/2008, at 3:33 AM, Jason van Zyl wrote:
Sure, I think it's important not to conflate additions to the simple
maneuver to attributes.
Agreed - what Niall proposed was in the scope of simplifying the
current POM, but adding new features like excludeAll is not.
Also just looking
Dan Fabulich wrote:
But neither does it seem right to insert #x0; when it's illegal XML.
Notably, Java will cheerfully print #x0; in XML if you tell it to do so, and
many parsers will figure out what to do with it just fine; the same applies
to #x07;.
Notably, Java's XML parser does NOT
Alexander Sack wrote:
Hey Vincent:
No problem. I would love to. I have a really really stupid question.
What I've done is:
1) Checked out the 2.0.x trunk
This is not necessary, you can use a regular Maven release.
2) Built a new maven-javadoc-plugin
3) Used mvn deploy:deploy-file to
roadtripryan wrote:
I am trying to test using TestNG/Spring/ and Maven Surefire 2.4.1.
My test suite runs great from within eclipse as individual tests or as a
whole suite. When I try and run the tests in Maven Surefire, however, they
fail. It appears Surefire is not calling the correct
I am trying to test using TestNG/Spring/ and Maven Surefire 2.4.1.
My test suite runs great from within eclipse as individual tests or as a
whole suite. When I try and run the tests in Maven Surefire, however, they
fail. It appears Surefire is not calling the correct @BeforeMethod method.
(When
I've published the new docs here:
http://maven.apache.org/plugins/maven-archetype-plugin/ . (It's
strange, the menu I see there doesn't match src/site/site.xml, but I'm
out of time to work on it.)
As you seem to use maven-site-plugin:2.0-beta-6, your problem might be
caused by MSITE-279 where
Sure, I think it's important not to conflate additions to the simple
maneuver to attributes.
Also just looking over the the thread, I don't think dependencyGroups
are necessary as I think many people, from my experience, expect a
dependency on a POM to yield the same result even though it
No ;-)
I have to review this because I think also that it can be dangerous
Arnaud
On Feb 11, 2008 11:11 AM, nicolas de loof [EMAIL PROTECTED] wrote:
I noticed the 2.5-SNAPSHOT-21 .pom of the eclipse plugin uses version
range
for org.eclipse.core:resource dependency.
Is there a good reason
I am very much for allowing simple types to be attribute-based. I think that
alone is worth the addition to Maven 2.1.
Paul
On Feb 11, 2008 7:19 AM, Emmanuel Venisse [EMAIL PROTECTED] wrote:
We don't use jpox 1.1.9 but 1.1.7
That explains it. :) Archiva switched to jpox 1.1.9, and we were
discussing it here-- I have local changes.
Well, heads up that it may be a problem if we upgrade!
--
Wendy
Well I'm actually thinking that we just make the change to allow
optional version for artifacts in the reactor, chopping the whole
section :)
- Brett
On 12/02/2008, at 2:21 PM, Ralph Goers wrote:
Actually, there wasn't a single dependency in that pom. Those were
all managed dependency
Should we emit #x0;, standards-be-damned?
Dangerous: If some parser goes fully-XML-compliant, they will blame Surefire
again. So just emitting #x0; seems not really a long-term solution.
(Expected but was ... Just imagine how painful it would be to track
something like that down.)
[...]
If I ever need an xml diver ill give you a ring :-P
But most folks I know don't care to swim in xml... They'd drownd...
--jason
-Original Message-
From: Don Brown [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 17:01:43
To:Maven Developers List dev@maven.apache.org
Subject: Re: An
Hehe. Nooo I was just being sarcastic in my traditional form.
I'd like to see some verbosity related changes to simplify the pom's structure
eventually... Cause IMO if we can describe the same data with less chars that
is going to be easier for folks to consume and manage Of course its
On Feb 12, 2008 1:26 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
Where did you run into this? I think not showing what it actually is
makes it immediately not obvious what's going wrong. So I'm for
showing what it actually is. Can you just wrap in CDATA?
As he wrote, these characters are
Heh, you would read it that way...well, I guess we do have a few crazy
POMs with pages and pages of Ant tags. If you love swimming in XML,
we have a small ocean over here :)
Don
On 2/12/08, Brett Porter [EMAIL PROTECTED] wrote:
Are you saying that if you are looking forward to dealing with
Atlassian is hiring ... :)
On 2/12/08, Jason Dillon [EMAIL PROTECTED] wrote:
IMO we should strive to make the pom even more verbose... So all us maven
folk can keep our jobbies :-P
--jason
-Original Message-
From: Brett Porter [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 16:35:35
IMO we should strive to make the pom even more verbose... So all us maven folk
can keep our jobbies :-P
--jason
-Original Message-
From: Brett Porter [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 16:35:35
To:Maven Developers List dev@maven.apache.org
Subject: Re: An Attribute Based POM
Yes, I happen to agree with the theory Shane and Jason outlined and is
why I accepted the status quo for 5 years :) But I always thought the
Maven dependencies tag in Ant looked better and was easier to read. I
think the expanded format makes more sense for machine-generated and -
read
Whether an attribute-based design is proper is a less important
question than what makes Maven more usable. Form should follow
function. What users care about is more readable POMs, less typing,
and less clutter. I've been really impressed with the Maven team
adopting a more programmatic
On 11-Feb-08, at 8:48 PM, Shane Isbell wrote:
I know that it is not always clear when to use and attribute and
when to use
an element; but typically, attributes are used to attach metadata or
nonessential information about an element, while subelements are
essential
parts of the parent
I know that it is not always clear when to use and attribute and when to use
an element; but typically, attributes are used to attach metadata or
nonessential information about an element, while subelements are essential
parts of the parent element. To me, the groupId, artifactId and version
would
sure but each project should not do that and using standard OO principles i
can encapsulate it in reusable artifacts
i average 5 deps per artifact and have (9 different) assemblies that result in
about 84 jars each, with no dependency management sections and i have
reproducible builds
by
Actually, there wasn't a single dependency in that pom. Those were all
managed dependency declarations. I'm not surprised to see something like
that, however it would really be better if it was:
dependencyManagement
dependency groupId=org.apache.maven.archiva
artifactId=bill-of-materials
Hey Vincent:
No problem. I would love to. I have a really really stupid question.
What I've done is:
1) Checked out the 2.0.x trunk
2) Built a new maven-javadoc-plugin
3) Used mvn deploy:deploy-file to install it on my test machine
4) Change my project's pom file that uses javadoc to
Jason van Zyl wrote:
Where did you run into this?
One of our integration tests says:
junit.framework.Assert.fail(\u);
When it's as bald as that it's not very important, but it's considerably
more likely when you Assert.assertEquals(expected, actual) where they both
contain control
I think we might be deviating from the normal pom a bit much here unless
you plan to support this in the regular pom processing also.
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, February 11, 2008 4:40 AM
To: Maven Developers List
Subject: Re: An Attribute
On 11-Feb-08, at 12:49 PM, Dan Fabulich wrote:
I didn't know this, so I imagine others might not. The string
#x0; is invalid XML. The character is simply not allowed in XML
in any representation. XML 1.0 standard blocks most of the
characters under x20, allowing only x9 xA and xD.
IMO
You can change the tool to make a bad pom look good but at the end of the day
there is something wrong if your declared dependency list looks like that...
Here are two different files for comparison (it halved the size):
Dan found his way in twice :)
Adding Wendy, that's 17 votes from the Maven PMC - a great turn out.
I will post it for the board to consider at the next meeting (Feb 20).
Cheers,
Brett
On 12/02/2008, at 10:38 AM, Emmanuel Venisse wrote:
Hi,
All the votes are +1, so the vote is accepted.
On Feb 5, 2008 4:06 PM, Emmanuel Venisse [EMAIL PROTECTED] wrote:
Hi,
Below is the current proposal for the Continuum TLP.
Please vote on whether to make this proposal a formal request to the Maven
PMC to apply for graduation.
[ ] +1
[ ] 0
[ ] -1
(A little late, but..) +1
--
Wendy
Hi,
All the votes are +1, so the vote is accepted. Here, the list of voters:
bindins: Vincent S., Dennis L., Trygve, Lukas, Dan F., Joakim, Jason, Jesse,
Brett, Carlos, Rahul, Maria, Arnaud, Olivier, John, Vincent M., Emmanuel
non-bindings: Napoleon, Henri, Dan, Edwin, Vivek
Thanks,
Emmanuel
Even perlookup instantiation (that seems to be the case) will not solve my
issue as I'm using the archiver multiple time in the *same* mojo execution :
* @parameter expression=${
component.org.codehaus.plexus.archiver.Archiver#jar}
* @required
*/
private JarArchiver archiver;
On Feb 11, 2008 1:23 PM, Brett Porter [EMAIL PROTECTED] wrote:
I'm collecting these up to put back into the wiki later on
Please, add also:
dependency ...
excludeAll/
/dependency
or something similar.
though
this initial attempt is intended not to change the model just yet
(though it's
I think this would be better served by just having dependencyGroup,
and inheriting something from that, and allowing them to be nested.
dependencyGroup groupId=org.apache.maven.archiva version=1.1-
SNAPSHOT
dependency artifactId=archiva-applet /
...
dependencyGroup version=1.0
Alexander,
Please open an issue, and if you want propose a patch :)
I guess that the pattern used should also work with -J-version
Vincent
2008/2/10, Alexander Sack [EMAIL PROTECTED]:
Exactly. The use of -fullversion is really for internal use as per
Benjamin and typically the format is java
Also what about a dependencyVersion
dependencies
dependencyGroup groupId=org.apache.maven.archiva
dependency artifactId=archiva-core version=${pom.version}/
dependencyVersion version=1.1-SNAPSHOT
dependency artifactId=archiva-applet/
dependency
Hello,
I need to build multiple archives from a mojo. I used a JarArchiver as
plexus component :
/**
* @parameter expression=${
component.org.codehaus.plexus.archiver.Archiver#jar}
* @required
*/
private JarArchiver archiver;
The generated jars grows as long as I create
On Feb 11, 2008 6:45 AM, Brett Porter [EMAIL PROTECTED] wrote:
Hi,
I've always wanted to see an attribute based POM, so based on Nicolas'
suggestion I killed some time after waking up early this morning to do
it.
JIRA: http://jira.codehaus.org/browse/MNG-3397
Here is a build to try:
I noticed the 2.5-SNAPSHOT-21 .pom of the eclipse plugin uses version range
for org.eclipse.core:resource dependency.
Is there a good reason do to this ?
This can introduces instability if new versions of this artifact are
deployed after the plugin has been released.
Nico.
Paul Gier wrote:
Sorry, I was thinking you were using svn. Maybe you should convert ;)
Yes, when I said the code is the same, I meant your project code minus
the changes to the pom.
So maybe you would need to do something like
1. checkout the tag
2. make a branch
3. check the code from the
Hmmm, spotted that one of my wishes got into my description of the current
main lifecycle, i.e. process-test-classes
I'm thinking that some of those process- phases are also hacks!
Once we have the ability to control the sequence of execution, those
process- phases could be removed... giving us
From
http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings
one critical advantage of Maven over Ant or other build systems is its
universal, intuitive set of verbs used to build any project, it is
imperative
that we preserve the meaning of
Reading through the Deterministic Lifecycle Planning page...
Do these changes make it possible to create new lifecycle phases???
Imho this would really help maven to become an extendable build/project
management tool for multiple platforms and purposes.
--
View this message in context:
Actually, this plugin can be used only to add new projects.
It use continuum-xmlrpc, so it will be easy to add new features.
Emmanuel
On Feb 10, 2008 8:00 PM, Wendy Smoak [EMAIL PROTECTED] wrote:
What is the status of the maven-continuum-plugin module?
I need a build (actually, a release,)
Exactly. The use of -fullversion is really for internal use as per
Benjamin and typically the format is java version version or something
of that elk which is very easy to parse. Again, I would rely on the
javadocVersion tag as a backup.
Thanks!
-aps
On Feb 10, 2008 3:22 PM, Benjamin Bentmann
On 2/12/08, Michael McCallum [EMAIL PROTECTED] wrote:
You can change the tool to make a bad pom look good but at the end of the
day
there is something wrong if your declared dependency list looks like
that...
How come? To get reproducible builds, you need to specify the versions of
all your
Are you saying that if you are looking forward to dealing with more
verbosity, you should interview at Atlassian? :)
On 12/02/2008, at 4:47 PM, Don Brown wrote:
Atlassian is hiring ... :)
On 2/12/08, Jason Dillon [EMAIL PROTECTED] wrote:
IMO we should strive to make the pom even more
On Feb 12, 2008 12:49 AM, Brett Porter [EMAIL PROTECTED] wrote:
Dan found his way in twice :)
oops.
Adding Wendy, that's 17 votes from the Maven PMC - a great turn out.
I will post it for the board to consider at the next meeting (Feb 20).
Thanks Brett.
Cheers,
Brett
On
We don't use jpox 1.1.9 but 1.1.7
Emmanuel
On Feb 10, 2008 7:47 PM, Wendy Smoak [EMAIL PROTECTED] wrote:
I'm having trouble building the trunk of Continuum. It's complaining
about:
Missing:
--
1) bcel:bcel:jar:5.2
...
Path to dependency:
1)
Thanks guys, will do this tonight. Arrghh, mvn install, not deploy, I don't
how I got those confused!
-aps
On Feb 11, 2008 5:56 PM, Vincent Siveton [EMAIL PROTECTED] wrote:
Hi,
More comments inside...
2008/2/11, Dennis Lundberg [EMAIL PROTECTED]:
Alexander Sack wrote:
Hey Vincent:
56 matches
Mail list logo
