Re: trunk and the super POM?

[Brett Porter]

Jason,

I don't entirely agree with all your points below, but agree with the  
move out of the super POM by a final 2.1 release so don't feel the  
need to go into it any further.


Just two questions remain unanswered:
- are the changes written down anywhere? As I said, I can't find the  
page in the wiki that I'm sure used to exist. If not, I will start it.
- I'm also interested in the question Wendy asked about whether the  
Clearcase/Perforce issues are already in JIRA?


Thanks,
Brett

On 30/10/2007, at 5:10 PM, Jason van Zyl wrote:



On 29 Oct 07, at 10:42 PM 29 Oct 07, Wendy Smoak wrote:


On 10/29/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

I doubt that given my visitation of production environments. But  
that
said the portion from our own POM provides the same  
functionality, or

it would even be preferable in subsequent versions of the release
plugin to make these goals default. The problem therein is selecting
the right version. Ultimately any sane group of developers wants to
see this information in their face. What is being used to produce  
the

release and what version of any tools/plugins being used.


Of course explicit configuration is better, but it's been in the  
super

pom for a long time now.


It's been out of the Super POM for quite a while now.


I think all Brett is asking is "How are we
going to help people transition from 2.0 to 2.1?"



To use what's in our own project POM as a working example of a best  
practice.



I agree that the release profile shouldn't be in the super pom, but
having it just disappear will be a shock.  Is there any way to
"deprecate" this behavior in 2.0, maybe by printing a message when  
the

release profile is activated?


Sure, in subsequent versions of the release plugin you can put a  
warning saying not to rely on the magic. We are not using it  
ourselves anymore, it is explicit in our POMs and has been for the  
last few releases.





I'm happily using the Continuum release functionality (but I think
it's the same code) and have used the release plugin for an Archiva
release.  It works fine.  (Yes, with Subversion.)


It's consistently crapped out for me with the last three releases  
of Maven itself. I think the problem is that the bugs fixed are  
primarily for Continuum and Archiva. I had to run it several times  
and then just reverted to the beta-5 release to get it to work. I  
reported the issues and had new ones with the 2.0.7 release, then  
had more where it let me go all the way and then died on an SVN  
discrepancy. Brian reported and fixed another critical one of late.



 Are the issues you
mentioned with Perforce and Clearcase entered in JIRA?






--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon/OSSummit roll call!

[Jason van Zyl]

On 29 Oct 07, at 10:30 PM 29 Oct 07, Kevin Jackson wrote:


I'm also interested in organising a Maven project BOF at each. Any
thoughts?


Could we discuss a way to allow the parser to include xml fragments to
prevent duplicate xml?  AFAIK the problem is with the plexus XML
parser that doesn't support entities


This would be supported by what we've called mixins which would be a  
very defined way to bring in new snippets of XML. Entities were  
suppressed by design to prevent N ways of end-running the management  
sections. We recognize the need to be a bit more flexible but were  
trying to prevent myriad ways of doing the same thing.


It is modello that is responsible for the parsing of the POM, not the  
Plexus XML parser. Coming to the BOF to discuss would be best coming  
with an implementation centre the discussion around. So far the ideas  
tossed around would centre around pulling snippets or mixins using a  
coordinate in much the same way we would pull other dependencies  
(though it could be an attribute for brevity). You can put a proposal  
in the user wiki if you want to try and define the rules which we can  
help you refine. The first use case that has been discussed is trying  
to provide a little block that would define all the latest release of  
plugins that people could easily include in their POMs to provide  
stability in using plugins in a reproducible way.






[ ] I'll be at ApacheCon US in Atlanta
[x] I'll be at OSSummit Asia in Hong Kong


Thanks,
Kev

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: trunk and the super POM?

[Jason van Zyl]

On 29 Oct 07, at 10:42 PM 29 Oct 07, Wendy Smoak wrote:


On 10/29/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


I doubt that given my visitation of production environments. But that
said the portion from our own POM provides the same functionality, or
it would even be preferable in subsequent versions of the release
plugin to make these goals default. The problem therein is selecting
the right version. Ultimately any sane group of developers wants to
see this information in their face. What is being used to produce the
release and what version of any tools/plugins being used.


Of course explicit configuration is better, but it's been in the super
pom for a long time now.


It's been out of the Super POM for quite a while now.


I think all Brett is asking is "How are we
going to help people transition from 2.0 to 2.1?"



To use what's in our own project POM as a working example of a best  
practice.



I agree that the release profile shouldn't be in the super pom, but
having it just disappear will be a shock.  Is there any way to
"deprecate" this behavior in 2.0, maybe by printing a message when the
release profile is activated?


Sure, in subsequent versions of the release plugin you can put a  
warning saying not to rely on the magic. We are not using it ourselves  
anymore, it is explicit in our POMs and has been for the last few  
releases.





I'm happily using the Continuum release functionality (but I think
it's the same code) and have used the release plugin for an Archiva
release.  It works fine.  (Yes, with Subversion.)


It's consistently crapped out for me with the last three releases of  
Maven itself. I think the problem is that the bugs fixed are primarily  
for Continuum and Archiva. I had to run it several times and then just  
reverted to the beta-5 release to get it to work. I reported the  
issues and had new ones with the 2.0.7 release, then had more where it  
let me go all the way and then died on an SVN discrepancy. Brian  
reported and fixed another critical one of late.



 Are the issues you
mentioned with Perforce and Clearcase entered in JIRA?






--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon/OSSummit roll call!

[Ralph Goers]

I'll be at ApacheCon.

Ralph

Brett Porter wrote:
I know several folks are presenting and will definitely be there, but 
I thought it might be good to send a shout out and see who is coming 
along? Hopefully we'll get some opportunities for getting together 
around the hackathon/code-a-ramas.


I'm also interested in organising a Maven project BOF at each. Any 
thoughts?


[ ] I'll be at ApacheCon US in Atlanta
[ ] I'll be at OSSummit Asia in Hong Kong

I'm planning to be at both with bells on.

Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven runs surefire plugin for testing by default. How to change this?

[Brett Porter]

I think you're looking for the surefire skip parameter - but this  
question belongs on the [EMAIL PROTECTED] list. Please reply  
there if necessary.


Thanks,
Brett

On 30/10/2007, at 2:48 PM, Kalyan Akella wrote:


Hi,

Recently, I developed a Java-based maven plugin intended to run in  
the test
phase of the maven build instead of the standard surefire-plugin.  
It has
just one goal, 'test'. When I configured my project's POM to  
include my
plugin for the testing phase and made sure the POM doesn't refernce  
surefire
anywhere, maven still invokes the surefire:test goal during the  
test phase.
Could someone please help me how to avoid maven running surefire  
plugin and

instead run mine.

Here are the details of my plugin POM and that of the Project POM:

Plugin POM:

4.0.0
sample.plugin
maven-sample-plugin
maven-plugin
1.0
My Sample Plugin


org.apache.maven
maven-plugin-api
2.0


  org.apache.maven
  maven-artifact
  2.0


junit
junit
4.4






org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5







Project POM:

4.0.0
sample.project
hello
1.0-SNAPSHOT
pom
Hello World

test



dev


${filters.dir}/dev-env.properties



sample.plugin
maven-sample-plugin
1.0



test

test

false



nfs

.*Test.class


.*Abstract.*Test.class
.*$.*.class
.*Poller.*.class











org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5



sample.plugin
maven-sample-plugin
1.0


test

test






.*Test.class


.*Abstract.*Test.class
.*$.*.class









Moreover, I included the following annotations while coding this  
plugin:

@requiresDependencyResolution test
@phase test
@goal test

Please help me. Thank you.
Sincere Regards,
Kalyan.


--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Profiles with id of default, broken feature

[Robert Ottaway]

Hello,

I have an issue, in that you can specify an id of 'default' for a  
profile and that profile is automatically and always activated. No  
mention of this little feature is made on the documentation page.


Here is the documentation: http://maven.apache.org/guides/ 
introduction/introduction-to-profiles.html.


The problem here is that a user would often want to name a profile  
"default", and they will not know the side effects of doing so. I  
know this because a developer at my work did so. This caused a bug  
that went uncaught for quite some time. Worse still, I've found the  
"default" profile stays activated even when another profile is  
activated explicitly via -P or a parameter. I checked this using "mvn  
clean help:active-profiles" while explicitly activating a number of  
profiles other than the default. Frankly this is a nasty hack of a  
feature. It would be proper to use the activeProfiles element to set  
up the profiles by default. I would vote to remove this 'feature' due  
to the confusion it can possibly cause, the fact no one bothered to  
even document it, and that it puts constraints on what an actual 'id'  
can be, which is malarky.


Something to ponder...
Create a simple project, add a profile named id. Add another called  
production. In each add a section of params that share the same name.  
Now try "mvn help:active-profiles package -Pproduction". You should  
see that both profiles are active! Even worse if you where trying to  
filter values into a file using the properties you set up, it is  
likely that the "default" values of the properties would be filtered  
into the file even with the "production" profile active.


I'd like to hear some thoughts from others about this feature.

cheers,
Rob O.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Maven runs surefire plugin for testing by default. How to change this?

[Kalyan Akella]

Hi,

Recently, I developed a Java-based maven plugin intended to run in the test
phase of the maven build instead of the standard surefire-plugin. It has
just one goal, 'test'. When I configured my project's POM to include my
plugin for the testing phase and made sure the POM doesn't refernce surefire
anywhere, maven still invokes the surefire:test goal during the test phase.
Could someone please help me how to avoid maven running surefire plugin and
instead run mine.

Here are the details of my plugin POM and that of the Project POM:

Plugin POM:

4.0.0
sample.plugin
maven-sample-plugin
maven-plugin
1.0
My Sample Plugin


org.apache.maven
maven-plugin-api
2.0


  org.apache.maven
  maven-artifact
  2.0


junit
junit
4.4






org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5







Project POM:

4.0.0
sample.project
hello
1.0-SNAPSHOT
pom
Hello World

test



dev


${filters.dir}/dev-env.properties



sample.plugin
maven-sample-plugin
1.0



test

test

false



nfs

.*Test.class


.*Abstract.*Test.class
.*$.*.class
.*Poller.*.class











org.apache.maven.plugins
maven-compiler-plugin

1.5
1.5



sample.plugin
maven-sample-plugin
1.0


test

test






.*Test.class


.*Abstract.*Test.class
.*$.*.class









Moreover, I included the following annotations while coding this plugin:
@requiresDependencyResolution test
@phase test
@goal test

Please help me. Thank you.
Sincere Regards,
Kalyan.

Re: trunk and the super POM?

[Wendy Smoak]

On 10/29/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

> I doubt that given my visitation of production environments. But that
> said the portion from our own POM provides the same functionality, or
> it would even be preferable in subsequent versions of the release
> plugin to make these goals default. The problem therein is selecting
> the right version. Ultimately any sane group of developers wants to
> see this information in their face. What is being used to produce the
> release and what version of any tools/plugins being used.

Of course explicit configuration is better, but it's been in the super
pom for a long time now.  I think all Brett is asking is "How are we
going to help people transition from 2.0 to 2.1?"

I agree that the release profile shouldn't be in the super pom, but
having it just disappear will be a shock.  Is there any way to
"deprecate" this behavior in 2.0, maybe by printing a message when the
release profile is activated?

I'm happily using the Continuum release functionality (but I think
it's the same code) and have used the release plugin for an Archiva
release.  It works fine.  (Yes, with Subversion.)   Are the issues you
mentioned with Perforce and Clearcase entered in JIRA?

-- 
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ApacheCon/OSSummit roll call!

[Kevin Jackson]

> I'm also interested in organising a Maven project BOF at each. Any
> thoughts?

Could we discuss a way to allow the parser to include xml fragments to
prevent duplicate xml?  AFAIK the problem is with the plexus XML
parser that doesn't support entities

> [ ] I'll be at ApacheCon US in Atlanta
> [x] I'll be at OSSummit Asia in Hong Kong

Thanks,
Kev

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ApacheCon/OSSummit roll call!

[Brett Porter]

I know several folks are presenting and will definitely be there, but  
I thought it might be good to send a shout out and see who is coming  
along? Hopefully we'll get some opportunities for getting together  
around the hackathon/code-a-ramas.


I'm also interested in organising a Maven project BOF at each. Any  
thoughts?


[ ] I'll be at ApacheCon US in Atlanta
[ ] I'll be at OSSummit Asia in Hong Kong

I'm planning to be at both with bells on.

Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: [RESULTS] [VOTE] Release Archiva 1.0-beta-3 (Postpone the release)

[Maria Odea Ching]

I can do another release at the end of this week :) Everybody okay with 
that?


-Deng

Brett Porter wrote:

I've merged 1.0-beta-4 back into 1.0-beta-3 in JIRA too.

When would you like to cut the release again Deng?

The only pre-condition I see is that we do need another plexus-webdav 
release first now - are all the webdav related JIRAs closed now Joakim?


Cheers,
Brett

On 26/10/2007, at 4:41 PM, Maria Odea Ching wrote:


These are the results of the vote:

+3 Binding votes (Fabrice, Brett and Myself)
-1 Binding vote (Arnaud)
+2 Non-binding votes (James, Olivier)

With all the regressions that were discovered in 1.0-beta-3, it seems 
that it would be better to postpone the release. I will remove the 
tag for 1.0-beta-3 in the source repo and revert the version in trunk 
to 1.0-beta-3-SNAPSHOT.


Thanks,
Deng

Maria Odea Ching wrote:

Hi All,

Archiva 1.0-beta-3 is now ready for release.

The highlights of this release are:
- major fixes in path resolution of artifacts (for proxying and 
consumers)

- fixes in updating of metadata files
- fixes in proxy connectors configuration
- tomcat deployment issues
- additional fixes in proxying
- form validations in webapp

The release notes for Archiva 1.0-beta-3 is available here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13660&styleName=Text&projectId=10980&Create=Create 
 




While the binaries including the sources, checksums and signatures 
can be found in:


http://people.apache.org/builds/maven/archiva/1.0-beta-3/

Everyone is encouraged to vote and give their feedback.

[ ] +1 Release it!
[ ] 0
[ ] -1 Don't release it, because...


The vote will be open for 72 hours. So, cast your votes now ;-)


Here's my +1


Thanks,
Deng


--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: trunk and the super POM?

[Jason van Zyl]

On 29 Oct 07, at 9:35 PM 29 Oct 07, William Ferguson wrote:




From: Jason van Zyl [mailto:[EMAIL PROTECTED]



Yes, I know we discussed it briefly at the time, but I
wanted to look at the actual implications for 2.0.x users now.



There are none, they aren't using it. And it's only
implication is in conjunction with the release plugin and the
release plugin should not be tied to any information in the
super POM. That's just wrong.



If anyone expects the same
behavior that then can put that chunk of the POM in theirs.
As of right now there are zero people affected and the
release plugins is pretty much useless to anyone who is not
using subversion. It's useless for Clearcase users and
useless for Perforce users which is a large part of the
enterprise environment so overall the clean up is the right
thing to do as it simply should not be in the Super POM and I
really doubt anyone can rely on it for production use. It's
just too flaky.



Jason, I agree that the release-plugin shouldn't be tied to any
information in the super POM.

But I think you'll find that there are *lots* of teams using the  
release

plugin in production environments.


I doubt that given my visitation of production environments. But that  
said the portion from our own POM provides the same functionality, or  
it would even be preferable in subsequent versions of the release  
plugin to make these goals default. The problem therein is selecting  
the right version. Ultimately any sane group of developers wants to  
see this information in their face. What is being used to produce the  
release and what version of any tools/plugins being used.



Its not perfect, the inability to
bind Mojos to its life-cycles is almost crippling, but it's the only
thing that remotely guarantees a consistent release process.


This will not change the way binaries are produced and released. The  
sources/javadocs not being release would affect IDE usage, but easier  
remedied with a snippet of our POM in the release plugin documentation.



So if this involves a large behaviour change for existing 2.0.x users
then there's going to need to be a suitable warning with an easy to
implement mitigation strategy.

William

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: trunk and the super POM?

[William Ferguson]

> From: Jason van Zyl [mailto:[EMAIL PROTECTED] 

> > Yes, I know we discussed it briefly at the time, but I 
> > wanted to look at the actual implications for 2.0.x users now.

> There are none, they aren't using it. And it's only 
> implication is in conjunction with the release plugin and the 
> release plugin should not be tied to any information in the 
> super POM. That's just wrong. 

> If anyone expects the same 
> behavior that then can put that chunk of the POM in theirs. 
> As of right now there are zero people affected and the 
> release plugins is pretty much useless to anyone who is not 
> using subversion. It's useless for Clearcase users and 
> useless for Perforce users which is a large part of the 
> enterprise environment so overall the clean up is the right 
> thing to do as it simply should not be in the Super POM and I 
> really doubt anyone can rely on it for production use. It's 
> just too flaky.


Jason, I agree that the release-plugin shouldn't be tied to any
information in the super POM.

But I think you'll find that there are *lots* of teams using the release
plugin in production environments. Its not perfect, the inability to
bind Mojos to its life-cycles is almost crippling, but it's the only
thing that remotely guarantees a consistent release process.

So if this involves a large behaviour change for existing 2.0.x users
then there's going to need to be a suitable warning with an easy to
implement mitigation strategy.

William

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: behaviour of old projects that use legacy repositories in 2.1?

[Jason van Zyl]

On 29 Oct 07, at 8:31 PM 29 Oct 07, Brett Porter wrote:



Ok, I can file that for starters.

I think we'll need to make clear instructions about setting up a  
repository manager to handle this scenario since I bet there are a  
lot of people using simple m1 repos internally for their m1  
projects. And notably the Sun m1 repository contains things that are  
not in their m2 repo - we need to be converting and syncing that to  
central if this feature is gone, IMO.




It's simply unbelievable the situation we have with them. That someone  
can't spend a few hours a week in their entire organization to fix  
this is ridiculous. I'm sure they can figure out how to convert their  
repositories. But I'm certainly not considering that as a valid  
argument for holding the rest of the world back. They can use 2.0.x.


The thing is that this is not about projects switching to m2, but  
their dependencies - and I've seen a bug filed as recently as this  
month looking for improved legacy repo support.




Anyone starting a new project will use m2. Given our resources and  
where the standard usage pattern is going it's time to cull the use of  
m1 repositories in Maven 2.1.x. That layout where a POM is not  
required just creates so much grief it's something we can just do  
without. Support will continue in 2.0.x but going forward it's  
something I think we can knock out. We just need to point people at  
the conversion tool. Yes, the people with lots of Jelly get dinged but  
we can't support everyone to do everything and 2.1 it's time to make  
the switch and get rid of that code. Again it's been two years.


Anyway, it's certainly one for the release notes - there used to be  
a page on the wiki tracking what has changed in a user-friendly  
format but I can't find it. Is it time to start one again?


Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: trunk and the super POM?

[Jason van Zyl]

On 29 Oct 07, at 8:24 PM 29 Oct 07, Brett Porter wrote:



On 30/10/2007, at 7:48 AM, Jason van Zyl wrote:



On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:


Hi,

I noticed that the super POM has changed on trunk (the removal of  
the release profile)


Long long time ago.


Yes, I know we discussed it briefly at the time, but I wanted to  
look at the actual implications for 2.0.x users now.


There are none, they aren't using it. And it's only implication is in  
conjunction with the release plugin and the release plugin should not  
be tied to any information in the super POM. That's just wrong. If  
anyone expects the same behavior that then can put that chunk of the  
POM in theirs. As of right now there are zero people affected and the  
release plugins is pretty much useless to anyone who is not using  
subversion. It's useless for Clearcase users and useless for Perforce  
users which is a large part of the enterprise environment so overall  
the clean up is the right thing to do as it simply should not be in  
the Super POM and I really doubt anyone can rely on it for production  
use. It's just too flaky.







, but the version hasn't yet - it's still 4.0.0. Also, IT 51 is  
excluded which checks the release profile.


For reasons of reproducibility, shouldn't POMs with the current  
modelVersion retain the same behaviour, and POMs with a newer  
version not receive the profile? Any objections to this being  
changed back?




Yes, don't put the release profile back. It's the completely wrong  
place for it.


You also don't change the model version didn't change the content  
did. The Super POM currently has no version itself which is what  
changes when content changes.


Leave it the way it is. It's been like that for a while. Putting  
the release information in there was a mistake.


Mistake as it may be, all I'm looking for is a solution that sees  
builds made with 2.0.x (that's everything up until today and for  
some time yet) build the same way with 2.1 when someone adds the  
flags for these that their now tagged projects expect.


It's not going away in the 2.0.x branch.




What alternative are you proposing? Is it simply going to be  
documented in the release notes as something like "you will no  
longer get source and javadoc when you build using the release  
profile and will need to add them to the build yourself"?


The alternative is like what we have in our own POM which defines  
everything literally and defines things where they are visible. So our  
POM would serve as an example for sure. I don't think foisting what we  
have in the Super POM on people is of any value. 2.1 is a major  
version change so it's the time to make the right corrections. If  
people move forward they live with the changes. I think this change is  
preferable as it's simply more visible and removes another element of  
black magic where a specific plugin pulls values from the Super POM. A  
typical user would have zero chance of figuring out how the release  
plugin actually works. They all presume it's controlled in some way in  
the plugin and the chances of someone finding that information in the  
Super POM are zero. It's not said where that information comes from at  
all in the documentation.


If they use the profile we have then they will get Javadocs, and  
sources but they might not want that so it means they can get whatever  
they want.





Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Continuum 1.1-beta-4

[Wendy Smoak]

On 10/25/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:

> Continuum 1.1-beta-4 is ready for release

+1 - looks good here, license and notice are in place, I added some m2
projects and tried a few things.

I don't care for the column title of "Nb Projects" on the summary
page.  How about "Total"?  And I'd put it on the far right so that it
reads like an equation:  success + failure + error = total

On the 'Edit' page for the group, the projects are not listed in the
same order as they are on the summary page.  (This caused me to move
the wrong project, since I chose the 'first' one, however...)

Moving projects between groups now works. :)

-- 
Wendy

Re: behaviour of old projects that use legacy repositories in 2.1?

[Brett Porter]

On 30/10/2007, at 7:51 AM, Jason van Zyl wrote:


Just warn and continue on its business.

Currently, it appears as if the path gets translated correctly,  
but it chokes on the lack of a POM file in the repository (this  
may also be an issue with builds that don't have POM files in the  
m2 repo, haven't checked).


Just wondering what to file in the bug :)



That it should just ignore it.


Ok, I can file that for starters.

I think we'll need to make clear instructions about setting up a  
repository manager to handle this scenario since I bet there are a  
lot of people using simple m1 repos internally for their m1 projects.  
And notably the Sun m1 repository contains things that are not in  
their m2 repo - we need to be converting and syncing that to central  
if this feature is gone, IMO.


The thing is that this is not about projects switching to m2, but  
their dependencies - and I've seen a bug filed as recently as this  
month looking for improved legacy repo support.


Anyway, it's certainly one for the release notes - there used to be a  
page on the wiki tracking what has changed in a user-friendly format  
but I can't find it. Is it time to start one again?


Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: trunk and the super POM?

[Brett Porter]

On 30/10/2007, at 7:48 AM, Jason van Zyl wrote:



On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:


Hi,

I noticed that the super POM has changed on trunk (the removal of  
the release profile)


Long long time ago.


Yes, I know we discussed it briefly at the time, but I wanted to look  
at the actual implications for 2.0.x users now.




, but the version hasn't yet - it's still 4.0.0. Also, IT 51 is  
excluded which checks the release profile.


For reasons of reproducibility, shouldn't POMs with the current  
modelVersion retain the same behaviour, and POMs with a newer  
version not receive the profile? Any objections to this being  
changed back?




Yes, don't put the release profile back. It's the completely wrong  
place for it.


You also don't change the model version didn't change the content  
did. The Super POM currently has no version itself which is what  
changes when content changes.


Leave it the way it is. It's been like that for a while. Putting  
the release information in there was a mistake.


Mistake as it may be, all I'm looking for is a solution that sees  
builds made with 2.0.x (that's everything up until today and for some  
time yet) build the same way with 2.1 when someone adds the flags for  
these that their now tagged projects expect.


What alternative are you proposing? Is it simply going to be  
documented in the release notes as something like "you will no longer  
get source and javadoc when you build using the release profile and  
will need to add them to the build yourself"?


Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release doxia-1.0-alpha-10

[Dennis Lundberg]

Hi,

Due to a couple of issues we need to release doxia-1.0-alpha-10, before 
we can start using it in the plugins. This time I will release doxia and 
doxia-sitetools separately, so that we don't confuse Continuum this 
time. A vote for doxia-sitetools-1.0-alpha-10 will follow.


Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780&styleName=Html&version=13770

Tags:
https://svn.apache.org/repos/asf/maven/doxia/doxia/tags/doxia-1.0-alpha-10/

Staged at:
http://people.apache.org/~dennisl/staging-repository-doxia/

The vote will be open for 72 hours.


Here is my +1

--
Dennis Lundberg

Re: behaviour of old projects that use legacy repositories in 2.1?

[Jason van Zyl]

On 29 Oct 07, at 11:04 AM 29 Oct 07, Brett Porter wrote:

What is the expected behaviour of legacy repository definitions in  
2.1?


Not supported. By the time 2.1 is actually released it will have been  
well over two years since 2.0. The support can exist in 2.0.x but  
anyone starting with 2.1 won't use it and with the conversion tools  
and native support in repositories managers it's not required.


I realise much of the handling was removed - is it expected it will  
just error out gracefully if one is encountered? Or the repo ignored?




Just warn and continue on its business.

Currently, it appears as if the path gets translated correctly, but  
it chokes on the lack of a POM file in the repository (this may also  
be an issue with builds that don't have POM files in the m2 repo,  
haven't checked).


Just wondering what to file in the bug :)



That it should just ignore it.


- Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: trunk and the super POM?

[Jason van Zyl]

On 29 Oct 07, at 10:47 AM 29 Oct 07, Brett Porter wrote:


Hi,

I noticed that the super POM has changed on trunk (the removal of  
the release profile)


Long long time ago.

, but the version hasn't yet - it's still 4.0.0. Also, IT 51 is  
excluded which checks the release profile.


For reasons of reproducibility, shouldn't POMs with the current  
modelVersion retain the same behaviour, and POMs with a newer  
version not receive the profile? Any objections to this being  
changed back?




Yes, don't put the release profile back. It's the completely wrong  
place for it.


You also don't change the model version didn't change the content did.  
The Super POM currently has no version itself which is what changes  
when content changes.


Leave it the way it is. It's been like that for a while. Putting the  
release information in there was a mistake.



Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r588144 - in /maven/components/trunk: maven-core/src/main/java/org/apache/maven/ maven-core/src/main/java/org/apache/maven/execution/ maven-core/src/main/java/org/apache/maven/extensio

[John Casey]

done
On Oct 25, 2007, at 7:30 PM, Jason van Zyl wrote:



On 25 Oct 07, at 3:36 PM 25 Oct 07, Carlos Sanchez wrote:


could you please keep the old methods and deprecate them with a
comment, if not keeping up with the changes becomes a nightmare



John, put the any additional things you need in the request. I made  
the request so that the signature wouldn't need to change in order  
to accommodate new things we needed.




On 10/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: jdcasey
Date: Wed Oct 24 22:13:22 2007
New Revision: 588144

URL: http://svn.apache.org/viewvc?rev=588144&view=rev
Log:
Improving the use of project sessions in the embedder, and  
exporting control over the project session map to the embedder  
instead of Maven.execute().


Modified:
maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/DefaultMaven.java
maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/Maven.java
maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/execution/MavenSession.java
maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/extension/DefaultBuildExtensionScanner.java
maven/components/trunk/maven-embedder/src/main/java/org/ 
apache/maven/embedder/MavenEmbedder.java


Modified: maven/components/trunk/maven-core/src/main/java/org/ 
apache/maven/DefaultMaven.java
URL: http://svn.apache.org/viewvc/maven/components/trunk/maven- 
core/src/main/java/org/apache/maven/DefaultMaven.java? 
rev=588144&r1=588143&r2=588144&view=diff
 
==
--- maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/DefaultMaven.java (original)
+++ maven/components/trunk/maven-core/src/main/java/org/apache/ 
maven/DefaultMaven.java Wed Oct 24 22:13:22 2007

@@ -63,7 +63,6 @@
 import java.util.ArrayList;
 import java.util.Collections;
 import java.util.Date;
-import java.util.HashMap;
 import java.util.Iterator;
 import java.util.List;
 import java.util.Map;
@@ -160,14 +159,12 @@
 return reactorManager;
 }

-public MavenExecutionResult execute( MavenExecutionRequest  
request )
+public MavenExecutionResult execute( MavenExecutionRequest  
request, Map projectSessions )

 {
 request.setStartTime( new Date() );

 MavenExecutionResult result = new  
DefaultMavenExecutionResult();


-Map projectSessions = new HashMap();
-
 ReactorManager reactorManager = createReactorManager(
 request,
 result,
@@ -192,66 +189,59 @@
 dispatcher,
 projectSessions );

-try
+for ( Iterator i = request.getGoals().iterator();  
i.hasNext(); )

 {
-for ( Iterator i = request.getGoals().iterator();  
i.hasNext(); )

-{
-String goal = (String) i.next();
-
-TaskValidationResult tvr =  
lifecycleExecutor.isTaskValid( goal, session,  
reactorManager.getTopLevelProject() );

+String goal = (String) i.next();

-if ( !tvr.isTaskValid() )
-{
-result.addBuildFailureException( new  
InvalidTaskException( tvr ) );
+TaskValidationResult tvr =  
lifecycleExecutor.isTaskValid( goal, session,  
reactorManager.getTopLevelProject() );


-return result;
-}
-}
-
-getLogger().info( "Scanning for projects..." );
-
-if ( reactorManager.hasMultipleProjects() )
+if ( !tvr.isTaskValid() )
 {
-getLogger().info( "Reactor build order: " );
-
-for ( Iterator i =  
reactorManager.getSortedProjects().iterator(); i.hasNext(); )

-{
-MavenProject project = (MavenProject) i.next();
+result.addBuildFailureException( new  
InvalidTaskException( tvr ) );


-getLogger().info( "  " + project.getName() );
-}
+return result;
 }
+}

-initializeBuildContext( request );
+getLogger().info( "Scanning for projects..." );

-try
-{
-lifecycleExecutor.execute(
-session,
-reactorManager,
-dispatcher );
-}
-catch ( LifecycleExecutionException e )
-{
-result.addLifecycleExecutionException( e );
-return result;
-}
-catch ( BuildFailureException e )
+if ( reactorManager.hasMultipleProjects() )
+{
+getLogger().info( "Reactor build order: " );
+
+for ( Iterator i = reactorManager.getSortedProjects 
().iterator(); i.hasNext(); )

 {
-result.addBuildFailureException( e );
-return result;
-}
+MavenProject project = (MavenProject) i.next

Re: When I submit a patch for a bug, how do I get someone's attention to merge it

[Matthew Flower]

No worries Brett, thanks for getting back to me.  :)

-m

- Original Message 
From: Brett Porter <[EMAIL PROTECTED]>
To: Maven Developers List 
Sent: Sunday, October 28, 2007 11:56:56 PM
Subject: Re: When I submit a patch for a bug, how do I get someone's attention 
to merge it


Generally, prodding is enough. Sometimes, it might require multiple  
attempts.

Archetype is particularly problematic, though, as the current trunk  
has a limited future as there is some work ongoing to rewrite it, but  
with no timeline for it replacing the current implementation. It's  
obviously not an ideal situation. The patch should be noticed and  
ported to the new code at a more suitable time later. Otherwise, if  
someone puts together another release on the current code it should  
dropped in there.

Apologies for the confusion.

Cheers,
Brett

On 29/10/2007, at 5:49 PM, Matthew Flower wrote:

> Does anybody have an answer for this?  I enjoy submitting patches,  
> but I'm not really willing to do them if they are going into a  
> black hole.
>
> Thanks,
> Matt
>
> - Original Message 
> From: Matthew Flower <[EMAIL PROTECTED]>
> To: dev@maven.apache.org
> Sent: Wednesday, October 24, 2007 3:46:05 PM
> Subject: When I submit a patch for a bug, how do I get someone's  
> attention to merge it
>
>
> Hi Guys,
>
> I recently submitted a patch to a problem listed in JIRA
>  (http://jira.codehaus.org/browse/ARCHETYPE-35) but I didn't hear any
>  response after a few weeks.  Do I need to post here to bring it to
>  someone's attention?  Maybe an email?
>
> I don't want to be a pest, I just don't know if there is some  
> unwritten
>  procedure I'm unaware of.  I have been following the instructions at
>  http://maven.apache.org/guides/development/guide-m2- 
> development.html#Creating_and_submitting_a_patch.
>
> Thanks,
> Matt
>
>
>
>

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CI builds are all passing

[Brett Porter]

With the exception of the integration tests on trunk (which I just  
sent a separate mail about), all the builds in Continuum are passing.  
I had to fix a few problems, though all were problems in the relevant  
tests under certain circumstances (and most were occurring locally  
for me as well), so they've come out better for it. For the first  
time in a long time I can build all the code in SCM.


I am confident in the results we are getting out of this - and have  
been watching them for some time.


That means - if there is a broken build on notifications@, and you  
committed something or to one of its dependencies, it's probably your  
fault and it needs to be fixed :) Continuum will also be nagging  
those that committed directly to the project at their @apache.org  
email addresses.


If the builds need any adjustments, drop a note here - several people  
have access to the configuration (and if anyone is changing the  
config, please drop a note here to say what you did).


Thanks!

Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: having Continuum deploy snapshots to the apache repository

[Brett Porter]

agreed - this was already on the list. You can see the list of things  
that are intended for the system here:

http://issues.apache.org/jira/browse/INFRA/component/12311662

On 30/10/2007, at 3:30 AM, Daniel Kulp wrote:



The only thing to be careful of is the size of the snapshots  
directory.

Infrastructure has been complaining off and on that various groups
aren't cleaning it up and it "grows and grows and grows".

I think if we had some way to cleanup older snapshots to keep the  
growth

in check, I'd be completely +1, but without that, I have concerns.

Dan


On Monday 29 October 2007, Brett Porter wrote:

I've just been trying to build a few things here and there today, and
found a mass of snapshots not deployed to the repository.

Given that Continuum has quietly been been performing reliably on the
zone and producing these snapshots, and is being properly monitored,
I'd like to have it ship them to the Apache snapshot repository, in
the same way we intend to for vmbuild using a sync from the
destination.

The upside would be that that problem should then be a thing of the
past (with the exception of the things that still don't build clean
anyway), and we'd also avoid having those permission problems.

The downsides are that you may have to wait a few hours for the sync
to take place, and that any snapshots you deploy yourself will be
overwritten.

I may not be able to get this in place immediately, but wanted to get
the ball rolling as this was a major pain today.

WDYT?

Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/




--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

behaviour of old projects that use legacy repositories in 2.1?

[Brett Porter]

What is the expected behaviour of legacy repository definitions in  
2.1? I realise much of the handling was removed - is it expected it  
will just error out gracefully if one is encountered? Or the repo  
ignored?


Currently, it appears as if the path gets translated correctly, but  
it chokes on the lack of a POM file in the repository (this may also  
be an issue with builds that don't have POM files in the m2 repo,  
haven't checked).


Just wondering what to file in the bug :)

- Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

active collections and IT tests

[Brett Porter]

John,

You might like to look at IT 0100 and IT 0102 here: http:// 
maven.zones.apache.org/continuum/surefireReport.action? 
buildId=32116&projectId=514&projectGroupId=40#org.apache.maven.its.Suite


It seems there's a problem with some recent changes?

If these aren't showing as issues in your environment, you might like  
to try with snapshots of the plugins used in the build as they might  
be trigger it (I'm currently just testing latest of everything, I  
haven't isolated the plugin local repositories - yet).


Cheers,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

trunk and the super POM?

[Brett Porter]

Hi,

I noticed that the super POM has changed on trunk (the removal of the  
release profile), but the version hasn't yet - it's still 4.0.0.  
Also, IT 51 is excluded which checks the release profile.


For reasons of reproducibility, shouldn't POMs with the current  
modelVersion retain the same behaviour, and POMs with a newer version  
not receive the profile? Any objections to this being changed back?


Thanks,
Brett

--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: having Continuum deploy snapshots to the apache repository

[Daniel Kulp]

The only thing to be careful of is the size of the snapshots directory.   
Infrastructure has been complaining off and on that various groups 
aren't cleaning it up and it "grows and grows and grows".  

I think if we had some way to cleanup older snapshots to keep the growth 
in check, I'd be completely +1, but without that, I have concerns.

Dan


On Monday 29 October 2007, Brett Porter wrote:
> I've just been trying to build a few things here and there today, and
> found a mass of snapshots not deployed to the repository.
>
> Given that Continuum has quietly been been performing reliably on the
> zone and producing these snapshots, and is being properly monitored,
> I'd like to have it ship them to the Apache snapshot repository, in
> the same way we intend to for vmbuild using a sync from the
> destination.
>
> The upside would be that that problem should then be a thing of the
> past (with the exception of the things that still don't build clean
> anyway), and we'd also avoid having those permission problems.
>
> The downsides are that you may have to wait a few hours for the sync
> to take place, and that any snapshots you deploy yourself will be
> overwritten.
>
> I may not be able to get this in place immediately, but wanted to get
> the ball rolling as this was a major pain today.
>
> WDYT?
>
> Cheers,
> Brett
>
> --
> Brett Porter - [EMAIL PROTECTED]
> Blog: http://www.devzuz.org/blogs/bporter/



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: LATEST, SNAPSHOT and RELEASE

[Nigel Magnay]

Yeah, that's what I thought.

What we've got is a number of projects that are being built with m2, and
dependencies between them. If the dependency is to 'in-development' code,
then it is usually pulled into an overall 'workspace' project with SVN
externals, and a property in the project is set to be (e.g.)
1.1-SNAPSHOT. The reactor then
works out the deps correctly, eclipse dependencies work, etc., etc.

Now occasionally a project will want to decouple itself from changes to the
shared project, so it cuts a release, changes their pom property, and often
removes the svn:externals link in their workspace, as they're now on a
'stable' build.

However, this of course breaks everyone else - they're still relying on the
'HEAD' being 1.1-SNAPSHOT, and now it's 1.2-SNAPSHOT. I had hoped they could
do something like LATEST to get
around that.

The only alternative I can think of is to have a ...
in our top-level company pom, and always release that in tandem with any
module release (and so use
${sharedstuff-latest})...


On 29/10/2007, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> I think LATEST and RELEASE apply to plugins only. SNAPSHOT is used in
> conjunction with a version. If you really don't care what version you
> get (curious) then use a range.
>
> -Original Message-
> From: Nigel Magnay [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 29, 2007 7:33 AM
> To: Maven Developers List
> Subject: LATEST, SNAPSHOT and RELEASE
>
> I could have sworn I'd read somewhere that it was possible to use
> dependency
> versions of LATEST, RELEASE and SNAPSHOT in a pom dependency to not have
> to
> specify which particular version I needed.
>
> Did I just dream that? Or does it not apply to dependencies?
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [continuum] BUILD FAILURE: Continuum Store

[Brett Porter]

sorry, my fault. killed the wrong build :D

On 30/10/2007, at 3:19 AM, [EMAIL PROTECTED] wrote:

Online report : http://maven.zones.apache.org/continuum/ 
buildResult.action?buildId=32081&projectId=113


Build statistics:
 State: Failed
 Previous State: Ok
 Started at: Mon 29 Oct 2007 16:18:49 +
 Finished at: Mon 29 Oct 2007 16:19:55 +
 Total time: 1m 5s
 Build Trigger: Schedule
 Build Number: 287
 Exit code: 1
 Building machine hostname: maven.zones.apache.org
 Operating system : SunOS(unknown)
 Java Home version :  java version "1.5.0_13"
 Java(TM) 2 Runtime Environment, Standard Edition (build  
1.5.0_13-b05)

 Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode)
Builder version :
 Maven version: 2.0.7
 Java version: 1.5.0_13
 OS name: "sunos" version: "5.10" arch: "x86"

** 
**

SCM Changes:
** 
**

No files changed

** 
**

Dependencies Changes:
** 
**

org.apache.maven.continuum:continuum-test:1.1-beta-5-SNAPSHOT

org.apache.maven.continuum:continuum-model:1.1-beta-5-SNAPSHOT

org.apache.maven.continuum:continuum-api:1.1-beta-5-SNAPSHOT

org.apache.maven.continuum:continuum-parent:1.1-beta-5-SNAPSHOT


** 
**

Build Defintion:
** 
**

POM filename: pom.xml
Goals: clean install   Arguments: --batch-mode --non-recursive
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Maven 2.0.7
Description:

** 
**

Test Summary:
** 
**

Tests: 0
Failures: 0
Total time: 0

** 
**

Output:
** 
**

[INFO] Scanning for projects...
[INFO]  
-- 
--

[INFO] Building Continuum Store
[INFO]task-segment: [clean, install]
[INFO]  
-- 
--

[INFO] [clean:clean]
[INFO] Deleting directory /export/home/build/data/continuum/ 
checkouts/113/target

[INFO] [plexus:descriptor {execution: default}]
[INFO] snapshot org.apache.maven.continuum:continuum-test:1.1- 
beta-5-SNAPSHOT: checking for updates from codehaus.org
[INFO] snapshot org.apache.maven.continuum:continuum-test:1.1- 
beta-5-SNAPSHOT: checking for updates from apache.snapshots
[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.

[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Resource directory does not exist: /export/home/build/data/ 
continuum/checkouts/113/src/main/resources

[INFO] Copying 1 resource
[INFO] Copying 2 resources
[INFO] [compiler:compile]
[INFO] Compiling 2 source files to /export/home/build/data/ 
continuum/checkouts/113/target/classes

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 2 resources
[INFO] [compiler:testCompile]
[INFO] Compiling 2 source files to /export/home/build/data/ 
continuum/checkouts/113/target/test-classes

[INFO] [surefire:test]
[INFO] Surefire report directory: /export/home/build/data/continuum/ 
checkouts/113/target/surefire-reports


---
T E S T S
---
Running org.apache.maven.continuum.store.ContinuumStoreTest
[INFO]  
-- 
--

[ERROR] BUILD FAILURE
[INFO]  
-- 
--

[INFO] There are test failures.

Please refer to /export/home/build/data/continuum/checkouts/113/ 
target/surefire-reports for the individual test results.
[INFO]  
-- 
--

[INFO] For more information, run Maven with the -e switch
[INFO]  
-- 
--

[INFO] Total time: 1 minute 3 seconds
[INFO] Finished at: Mon Oct 29 16:19:55 GMT+00:00 2007
[INFO] Final Memory: 15M/331M
[INFO]  
-

Re: [vote] Release Continuum 1.1-beta-4

[Brett Porter]

+1

I checked the new license and notice, and checked that it started up  
ok from scratch - happy to go ahead with the beta release.


- Brett

On 25/10/2007, at 5:10 PM, Emmanuel Venisse wrote:


Hi,

Continuum 1.1-beta-4 is ready for release

The highlights are
 - lot of bug fixes
 - A new page to view the build queue
 - Customization of mail subject

The Release Notes is available there: http://jira.codehaus.org/ 
secure/IssueNavigator.jspa?reset=true&pid=10540&fixfor=13727


The binaries are available there:
 - Runtime: http://people.apache.org/builds/maven/continuum/1.1- 
beta-4/org/apache/maven/continuum/continuum-plexus-runtime/1.1- 
beta-4/continuum-plexus-runtime-1.1-beta-4-bin.tar.gz
 - Webapp: http://people.apache.org/builds/maven/continuum/1.1- 
beta-4/org/apache/maven/continuum/continuum-webapp/1.1-beta-4/ 
continuum-webapp-1.1-beta-4.war
 - data management cli: http://people.apache.org/builds/maven/ 
continuum/1.1-beta-4/org/apache/maven/continuum/data-management-cli/ 
1.1-beta-4/data-management-cli-1.1-beta-4-app.jar


Everyone is encouraged to vote and give their feedback.

[ ]  +1  Release it!
[ ]   0
[ ]  -1  Don't release it, because...


The vote will be open for 72 hours. So, cast your votes now ;-)

Here's my +1

Thanks,
Emmanuel


--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

Re: Doxia docbook module requirements

[Lukas Theussl]

FYI: I have fixed a few issues that were within my reach :), for the 
rest I have opened a jira: http://jira.codehaus.org/browse/DOXIA-184


-Lukas

Lukas Theussl wrote:
I've just checked the output of the identity test for the docbook 
module, below is a list of discrepancies (note: the identity test 
doesn't tell you where the problem is, it could be in the parser or in 
the sink, or both). These are definetely bugs and I'd be happy to apply 
your patches if they fix any of those! :)


- head is emitted within body instead of before
- no author and date elements
- no sectionTitle elements
- numbered list items are emitted as normal list items
- figure- and table captions are emitted as sectionTitle5
- paragraphs are inserted in table cells
- no tableRows element
- no tableHeaderCell element
- bold events end up as italic
- anchors are modified
- lineBreak and horizontalRule end up as comments


In general, if you are unsure, just attach your patch in jira so we can 
have a look at it.


Thanks!
-Lukas

Jon Card wrote:




I’m an instructor at a consulting company and I’ve been writing my 
labs and teaching materials in APT as a part of the software project 
that are used as part of the lab. I’m using Maven to convert that to 
Docbook and FOP to convert that to PDF. The problem has been that I 
didn’t like the output of the docbook component. Over the last week, 
I’ve “fixed” the elements of the docbook module and docbook renderer 
that I didn’t like. I’m willing to give that code back as a 
contribution to the project, but I don’t know why it was written the 
way it was in the first place. I haven’t had a chance to check Jira to 
see if these are bugs that are already registered, but I will. How do 
I know if I’ve “fixed” something that was written in particular way on 
purpose?


 


The biggest things I’ve fixed are:

 

A section with a title of “the title” and paragraph “the paragraph” 
was being rendered as “the titlethe 
paragraph”, when it should be “the 
titlethe paragraph”.


 

A book rendered will have a “chapter” as the top-level element, when 
it would seem more proper to have a “book” element as the top-level, 
particularly as the module, in some other configuration that I don’t 
yet understand, would render “article” as the top-level element, and 
“book” and “article” are peers in the schema.


 

A Doxia book descriptor lists a “book”, which has “chapters”, which 
has “sections” that correspond to (in my case) APT files. The output 
that’s rendered has a “chapter” element as the root, which has 
“sections” that correspond to (in my case) APT files, but no 
distinction is made between APT files that are listed in the Doxia 
book descriptor as being in different (Doxia) “chapters”. Even if you 
are making a (Doxia) “book” correspond to a (Docbook) “chapter”, 
shouldn’t the hierarchy of the book descriptor be reflected in the 
hierarchy in the target?


 

The Doxia book descriptor allows the specification of a title and 
author of a “book”, “chapter”, and “section”. The rendition always 
takes these from the source documents. I have the system taking them 
from the source document, but giving priority to the Doxia book 
descriptor.


 

If you don’t like what I’ve done, I’m happy to deploy this to our 
company repository and keep it for myself. If there’s some 
documentation or discussion as to why it was implemented the way it’s 
been done, I’d like to see it; maybe I didn’t see something. If 
there’s other use cases (I’ve been focusing on the docbook module used 
in the book rendering mode) that I can test, I’ll do that before 
sending any patches. If you’d like me to log these as bugs in Jira, 
I’ll do that, too. I just don’t even know if you’d want what I did.


 

 


Jon Card
Crown Partners
O 303.350.1115
M 303.916.3966
F 303.770.9054
[EMAIL PROTECTED]   


 

 

 
 
 

Crown Partners is pleased to announce the acquisition of Phoenix 
Systems, Platform Dynamics US, and Platform Dynamics Europe 
(www.platformdynamics.net ). This 
integration reiterates our commitment to Enterprise Content Management 
software products, premier services and global expansion.


Crown is also identified as America’s 101^st fastest growing, 
privately held, software company in 2007 by Inc Magazine’s Inc500 
list.  See us at www.crownpartners.com 
. This is the second year in a row that 
Crown has been identified in the prestigious Inc500 list.


 

This communication and all accompanying attachments and related 
information and data is confidential and proprietary information of 
Crown Partners, LLC.  This communication is intended solely for 
receipt by the intended recipient. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, 
distributing or using any of this information. If you received this 
communication in error, please contact the sender immediately and 
dest

Problem accessing dependency resource via reflection in maven 2 plugin

[Gary Weaver]

Hello,

(I apologize in advance if this issue was addressed already. Jira ticket 
at: http://jira.codehaus.org/browse/MNG-3262 which contains the source 
and pom of the plugin and project that uses the plugin)


Wondering if anyone can spot anything stupid I'm doing here...

I've written a Maven 2 mojo that is having trouble instantiating (via 
reflection) a properties resource of dependency that is included as a 
"compile"-scope dependency in the project (pom.xml) that is utilizing my 
plugin.


(Even though I need the plugin to access a dependency that is in 
"provided" scope, for now I'm using compile scope since the maven 
documentation states that @requiresDependencyResolution doesn't support 
provided scope.)


Here are the details:

1) I have the following dependency:

---start---
   
   
   com.atlassian.confluence
   confluence
   2.6.0
   compile
   
   
---end---

2) In the pom.xml of the project that utilizes my plugin, the mojo of 
the plugin I wrote is configured with the execution:


---start---
   
   get_ConfluenceActionSupport.properties
   compile
   
   extractProperties
   
   
   
com.atlassian.confluence.core.ConfluenceActionSupport.properties
   
target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties

   
   
---end---

3) In the Maven 2 mojo it calls the following code (just copied/pasted 
the relevant portion):


---start---
   // load properties with reflection and save to file
   InputStream in = null;
   OutputStream out = null;

   boolean foundFile = false;
   try {
   String resource = cleanResourceName(fullyQualifiedProperties);
   System.out.println("Getting " + resource);
   in = getClass().getResourceAsStream (resource);
   if (in != null)
   {
   Properties result = new Properties();
   result.load (in); // Can throw IOException
   out = new BufferedOutputStream(new 
FileOutputStream(outputPathname));

   result.store(out, "");
   foundFile = true;
   }
   }
---end---

When executed, it can't find the properties file in the classloader. As 
you can see from the following output, I'm putting the resource string 
together correctly as 
"/com/atlassian/confluence/core/ConfluenceActionSupport.properties" 
which if you interrogate the above confluence dependency, you should be 
able to find.


---start---
[INFO] [i18nsanity-pt:extractProperties {execution: 
get_ConfluenceActionSupport.properties}]
[INFO] Extracting properties file from classpath... 
fullyQualifiedProperties=com.atlassian.confluence.core.ConfluenceActionSupport.properties 
outputFile=/usr/svn/community/confluence/plugins/americanenglishlanguagepack/trunk/target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties

Getting /com/atlassian/confluence/core/ConfluenceActionSupport.properties
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed properties extraction!

Embedded error: Could not find properties file on classpath: 
com.atlassian.confluence.core.ConfluenceActionSupport.properties

---end---


Thanks!

--
Gary Weaver
Internet Framework Services
Office of Information Technology
Duke University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: LATEST, SNAPSHOT and RELEASE

[Brian E. Fox]

I think LATEST and RELEASE apply to plugins only. SNAPSHOT is used in
conjunction with a version. If you really don't care what version you
get (curious) then use a range.

-Original Message-
From: Nigel Magnay [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 29, 2007 7:33 AM
To: Maven Developers List
Subject: LATEST, SNAPSHOT and RELEASE

I could have sworn I'd read somewhere that it was possible to use
dependency
versions of LATEST, RELEASE and SNAPSHOT in a pom dependency to not have
to
specify which particular version I needed.

Did I just dream that? Or does it not apply to dependencies?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

LATEST, SNAPSHOT and RELEASE

[Nigel Magnay]

I could have sworn I'd read somewhere that it was possible to use dependency
versions of LATEST, RELEASE and SNAPSHOT in a pom dependency to not have to
specify which particular version I needed.

Did I just dream that? Or does it not apply to dependencies?

Re: svn commit: r589518 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java

[Brett Porter]

yep - thanks for taking care of that!

On 29/10/2007, at 8:34 PM, Stephane Nicoll wrote:

It's fixed. Can you test on your end and uncomment the test back if  
it's ok?


Thanks,
Stéphane

On 10/29/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:

What's the probem?

Thanks,
Stéphane

-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Oct 29, 2007 7:38 AM
Subject: svn commit: r589518 -
/maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/ 
maven/plugin/ear/EarMojoTest.java

To: [EMAIL PROTECTED]


Author: brett
Date: Sun Oct 28 23:38:04 2007
New Revision: 589518

URL: http://svn.apache.org/viewvc?rev=589518&view=rev
Log:
comment out test that is failing in my env and CI

Modified:
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/ 
maven/plugin/ear/EarMojoTest.java


Modified: maven/plugins/trunk/maven-ear-plugin/src/test/java/org/ 
apache/maven/plugin/ear/EarMojoTest.java
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear- 
plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java? 
rev=589518&r1=589517&r2=589518&view=diff
= 
=
--- maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/ 
maven/plugin/ear/EarMojoTest.java

(original)
+++ maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/ 
maven/plugin/ear/EarMojoTest.java

Sun Oct 28 23:38:04 2007
@@ -446,7 +446,8 @@
 public void testProject042()
 throws Exception
 {
-doTestProject( "project-042", new
String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
+// TODO: fix chronically failing test
+// doTestProject( "project-042", new
String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
 }

 }




--
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge




--
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r589518 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java

[Stephane Nicoll]

It's fixed. Can you test on your end and uncomment the test back if it's ok?

Thanks,
Stéphane

On 10/29/07, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> What's the probem?
>
> Thanks,
> Stéphane
>
> -- Forwarded message --
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Oct 29, 2007 7:38 AM
> Subject: svn commit: r589518 -
> /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
> To: [EMAIL PROTECTED]
>
>
> Author: brett
> Date: Sun Oct 28 23:38:04 2007
> New Revision: 589518
>
> URL: http://svn.apache.org/viewvc?rev=589518&view=rev
> Log:
> comment out test that is failing in my env and CI
>
> Modified:
> 
> maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
>
> Modified: 
> maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
> URL: 
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java?rev=589518&r1=589517&r2=589518&view=diff
> ==
> --- 
> maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
> (original)
> +++ 
> maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
> Sun Oct 28 23:38:04 2007
> @@ -446,7 +446,8 @@
>  public void testProject042()
>  throws Exception
>  {
> -doTestProject( "project-042", new
> String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
> +// TODO: fix chronically failing test
> +// doTestProject( "project-042", new
> String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
>  }
>
>  }
>
>
>
>
> --
> Large Systems Suck: This rule is 100% transitive. If you build one,
> you suck" -- S.Yegge
>


-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fwd: svn commit: r589518 - /maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java

[Stephane Nicoll]

What's the probem?

Thanks,
Stéphane

-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Oct 29, 2007 7:38 AM
Subject: svn commit: r589518 -
/maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
To: [EMAIL PROTECTED]


Author: brett
Date: Sun Oct 28 23:38:04 2007
New Revision: 589518

URL: http://svn.apache.org/viewvc?rev=589518&view=rev
Log:
comment out test that is failing in my env and CI

Modified:

maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java

Modified: 
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java?rev=589518&r1=589517&r2=589518&view=diff
==
--- 
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
(original)
+++ 
maven/plugins/trunk/maven-ear-plugin/src/test/java/org/apache/maven/plugin/ear/EarMojoTest.java
Sun Oct 28 23:38:04 2007
@@ -446,7 +446,8 @@
 public void testProject042()
 throws Exception
 {
-doTestProject( "project-042", new
String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
+// TODO: fix chronically failing test
+// doTestProject( "project-042", new
String[]{"ejb-sample-one-1.0.jar", "ejb-sample-two-1.0.jar"} );
 }

 }




-- 
Large Systems Suck: This rule is 100% transitive. If you build one,
you suck" -- S.Yegge

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]