Re: Migration complete: changes, changelog, jxr and surefire report plugins

[Brett Porter]

Right... I was referring to the m1 version :)

Edwin Punzalan wrote:
> 
> fyi, I've seen changelog and it already uses maven-scm
> 
> 
> Brett Porter wrote:
>> I've been in favour of this since day 1. JXR, for example, is almost
>> entirely shared.
>>
>> For changelog, this will happen by refactoring to Maven SCM. For
>> changes/jira/announcement, it will be by refactoring around
>> issue-management library in the sandbox.
>>
>> The Surefire report looks the same, but is completely different. That
>> said, m1 could use it as a replacement for the JSL based junit-report.
>> I'll leave that up to you :)
>>
>> It's essential that the m1 plugins be refactored around java code for
>> this to be feasible though. That's the reason JXR was so straight
>> forward.
>>
>> Cheers,
>> Brett
>>
>> Arnaud HERITIER wrote:
>>  
>>> I'm seeing that we are duplicating/adapting code between plugins in
>>> m1 and
>>> m2.
>>> Can't we try to create some shared libraries to use them in both
>>> plugins ?
>>> We could we create them ?
>>>
>>> Is it interesting ?
>>>
>>> Arnaud
>>>
>>> On 3/22/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>>>
 Hi,

 The migration of these plugins from mojo to the Maven sandbox is
 complete.

 I will work on JXR and Surefire to get them released and promoted,
 soon.
 The others require more work, so if you are able to contribute,
 please do!

 I have not yet moved the dependency plugin - since to date Brian has
 worked solely on that, he can commit it to the plugins repo after his
 account is created (CLA is already filed).

 - Brett

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


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

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

Re: Migration complete: changes, changelog, jxr and surefire report plugins

[Edwin Punzalan]

fyi, I've seen changelog and it already uses maven-scm


Brett Porter wrote:

I've been in favour of this since day 1. JXR, for example, is almost
entirely shared.

For changelog, this will happen by refactoring to Maven SCM. For
changes/jira/announcement, it will be by refactoring around
issue-management library in the sandbox.

The Surefire report looks the same, but is completely different. That
said, m1 could use it as a replacement for the JSL based junit-report.
I'll leave that up to you :)

It's essential that the m1 plugins be refactored around java code for
this to be feasible though. That's the reason JXR was so straight forward.

Cheers,
Brett

Arnaud HERITIER wrote:
  

I'm seeing that we are duplicating/adapting code between plugins in m1 and
m2.
Can't we try to create some shared libraries to use them in both plugins ?
We could we create them ?

Is it interesting ?

Arnaud

On 3/22/06, Brett Porter <[EMAIL PROTECTED]> wrote:


Hi,

The migration of these plugins from mojo to the Maven sandbox is complete.

I will work on JXR and Surefire to get them released and promoted, soon.
The others require more work, so if you are able to contribute, please do!

I have not yet moved the dependency plugin - since to date Brian has
worked solely on that, he can commit it to the plugins repo after his
account is created (CLA is already filed).

- Brett

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


  


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

  


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

[jira] Subscription: Outstanding Repository Maintenance: Uploads

[jira]

Issue Subscription
Filter: Outstanding Repository Maintenance: Uploads (14 issues)
Subscriber: mavendevlist


Key Summary
MAVENUPLOAD-785Java Tree Builder 1.3.2
http://jira.codehaus.org/browse/MAVENUPLOAD-785
MAVENUPLOAD-789Tomcat 5.5.15 poms for existing jars
http://jira.codehaus.org/browse/MAVENUPLOAD-789
MAVENUPLOAD-783Please upload QALAb 0.8.0
http://jira.codehaus.org/browse/MAVENUPLOAD-783
MAVENUPLOAD-784Please upload maven-qalab-plugin 0.8.0
http://jira.codehaus.org/browse/MAVENUPLOAD-784
MAVENUPLOAD-787itext-1.3.6, itext 1.4
http://jira.codehaus.org/browse/MAVENUPLOAD-787
MAVENUPLOAD-788Databinder 0.4 upload request
http://jira.codehaus.org/browse/MAVENUPLOAD-788
MAVENUPLOAD-786Wicket 1.2 beta2 upload request
http://jira.codehaus.org/browse/MAVENUPLOAD-786
MAVENUPLOAD-778Please update 2.3.5 version of Freemarker library
http://jira.codehaus.org/browse/MAVENUPLOAD-778
MAVENUPLOAD-776Test utility classes for ANT 1.6.5 (binaries and sources)
http://jira.codehaus.org/browse/MAVENUPLOAD-776
MAVENUPLOAD-772could someone upload the new JConnector 3.1.12
http://jira.codehaus.org/browse/MAVENUPLOAD-772
MAVENUPLOAD-759Glassfish persistence and transaction apis
http://jira.codehaus.org/browse/MAVENUPLOAD-759
MAVENUPLOAD-725Please upload displaytag 12 tld
http://jira.codehaus.org/browse/MAVENUPLOAD-725
MAVENUPLOAD-735Please upload com.sun.xml:xalan 1.0.4
http://jira.codehaus.org/browse/MAVENUPLOAD-735
MAVENUPLOAD-736Please upload com.sun.xml:xercesImpl 1.0.4
http://jira.codehaus.org/browse/MAVENUPLOAD-736


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

[jira] Subscription: Outstanding Repository Maintenance: Evangelism

[jira]

Issue Subscription
Filter: Outstanding Repository Maintenance: Evangelism (27 issues)
Subscriber: mavendevlist


Key Summary
MEV-362 missing jar for relocation of netbeans:cvslib:3.6
http://jira.codehaus.org/browse/MEV-362
MEV-360 nanocontainer has invalid xpp3 dependency
http://jira.codehaus.org/browse/MEV-360
MEV-361 picocontainer has invalid xpp3 dependency
http://jira.codehaus.org/browse/MEV-361
MEV-358 Missing POMs for Spring 2.0-m3
http://jira.codehaus.org/browse/MEV-358
MEV-339 Missing POMs for Spring 2.0-m2
http://jira.codehaus.org/browse/MEV-339
MEV-352 Relocate cvslib in netbeans groupId to cvsclient in org.netbeans.lib
http://jira.codehaus.org/browse/MEV-352
MEV-356 Missing dep on jboss-common in jbossmq-client & jnp-client 4.0.2
http://jira.codehaus.org/browse/MEV-356
MEV-353 I need to have these 4 pom's posted to reference some bea 3rd party 
artifacts to support the weblogic plugin
http://jira.codehaus.org/browse/MEV-353
MEV-351 xmlc-xerces-2.2.7.1.jar is unnecessary and  xmlc-apis.jar is 
required.
http://jira.codehaus.org/browse/MEV-351
MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded 
variables
http://jira.codehaus.org/browse/MEV-296
MEV-326 Spring 2.0 M2 is missing a POM
http://jira.codehaus.org/browse/MEV-326
MEV-337 OJB 1.0.4 has a number of dependencies that should be optional
http://jira.codehaus.org/browse/MEV-337
MEV-334 Stax POM points to an invalid XMLBeans dependency
http://jira.codehaus.org/browse/MEV-334
MEV-331 Please upload Acegi Security 1.0.0 RC2
http://jira.codehaus.org/browse/MEV-331
MEV-330 WebWork 2.2.1 POM should list FreeMarker as a dependency since it's 
required for plain ol' JSPs
http://jira.codehaus.org/browse/MEV-330
MEV-325 Description of jaxb-api 1.0.1 is wrong
http://jira.codehaus.org/browse/MEV-325
MEV-313 publish seperate spring POM's for seperate dependencies
http://jira.codehaus.org/browse/MEV-313
MEV-277 More Spring Dependencies Should be Optional
http://jira.codehaus.org/browse/MEV-277
MEV-320 Hibernate 3.1.x POMs pull in Sun jars
http://jira.codehaus.org/browse/MEV-320
MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype
http://jira.codehaus.org/browse/MEV-201
MEV-173 xmlpull JARs exist in two different places on ibiblio
http://jira.codehaus.org/browse/MEV-173
MEV-48  openejb poms
http://jira.codehaus.org/browse/MEV-48
MEV-45  Full list of poms that doesn't respect the m2 format
http://jira.codehaus.org/browse/MEV-45
MEV-36  Exo POM(s) missing dependency versions
http://jira.codehaus.org/browse/MEV-36
MEV-33  XOM POM references xercesImpl v.2.2.1 which does not exist in repo
http://jira.codehaus.org/browse/MEV-33
MEV-31  XOM POM references xmlParserAPIs v2.6.1 which is not in the repo
http://jira.codehaus.org/browse/MEV-31
MEV-20  clean up bad IDs in the repository
http://jira.codehaus.org/browse/MEV-20


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

Re: Distributed Continuum (GBuild)

[Brett Porter]

+1. I've been really looking forward to it.

Jason van Zyl wrote:
> Hi,
> 
> I have been talking with David Blevins about moving the GBuild code from
> Geronimo over to Continuum proper. GBuild is a version of Continuum that
> works in a distributed fashion. GBuild was created to test the Geronimo
> TCK across many different platforms with many different configurations
> and have the results all aggregated back on a master machine.
> 
> So what I would like to propose is to move the code from GBuild over
> into Continuum proper and give David Blevins and Kevan Miller commit
> access. They are both committers on the Geronimo project and are
> familiar with this distributed code and will continue to work on the
> code once in Continuum.
> 
> This is very exciting!
> 
> Here's my
> 
> +1
> 
> Jason van Zyl
> 

Re: Implementing support for CM Synergy?

[Emmanuel Venisse]

If you extend the maven-scm-providers pom like other providers, it will be more easy to start with 
dependencies.


Emmanuel

Torbjorn Smorgrav a écrit :

Hi Henrik!

I posted this yesterday as well. But I haven't got any response yet. So 
I'll ask again.

I want to implement support for CM Synergy.


I'll be happy to help you. 
I recently added the Bazaar provider (yet to be released) so I can 

at least guide you through the same path that I took. 


What baseline should I use?


Use the current development baseline.
http://maven.apache.org/scm/source-repository.html
 


What do I need to check out?


Start with:

maven-scm-api/ 


maven-scm-test/ 


And a reference provider eg. maven-scm-provider-bazaar/
 

Perhapes choose one that is most similar to the CM Synergy


What class or interfaced do I need to implement?


What I did was change the implementation of an existing provider.
That way I got fast results and I learned the API one step at the time.


Basically what you need to implements is an (Abstract)ScmProvider and its 
commands.


How can I test my provider?


1. Run unit tests from your IDE
The test classes in maven-scm-test was really helpfull to me. Try to include a 
tck test

as soon as possible. See how the tck tests are implemented in the reference 
provider (its a no brainer :).

It can be a bit tricky to setup your IDE to pickup your current modifications and not the installed 


version of the provider. Let me know it this becomes a problem.

2. Build and install the provider and test it with eg. "mvn scm:checkout" on a 
project where
you have defined a scm url in the pom.xml.


This was probably a too short answer. But if you post your questions as they 
come,
I'll do my best to help you. And in the end I like to make a mave-scm howto 
webpage
with all of this.

Good luck,
Torbjørn

Re: Implementing support for CM Synergy?

[Torbjorn Smorgrav]

Hi Henrik!> I posted this yesterday as well. But I haven't got any response yet. So > I'll ask again.> I want to implement support for CM Synergy.I'll be happy to help you. I recently added the Bazaar provider (yet to be released) so I can 
at least guide you through the same path that I took. > What baseline should I use?Use the current development baseline.http://maven.apache.org/scm/source-repository.html
> What do I need to check out?Start with:maven-scm-api/
maven-scm-test/And a reference provider eg. maven-scm-provider-bazaar/
Perhapes choose one that is most similar to the CM Synergy> What class or interfaced do I need to implement?What I did was change the implementation of an existing provider.That way I got fast results and I learned the API one step at the time.
Basically what you need to implements is an (Abstract)ScmProvider and its commands.> How can I test my provider?1. Run unit tests from your IDEThe test classes in maven-scm-test was really helpfull to me. Try to include a tck test
as soon as possible. See how the tck tests are implemented in the reference provider (its a no brainer :).It can be a bit tricky to setup your IDE to pickup your current modifications and not the installed 
version of the provider. Let me know it this becomes a problem.2. Build and install the provider and test it with eg. "mvn scm:checkout" on a project whereyou have defined a scm url in the pom.xml.
This was probably a too short answer. But if you post your questions as they come,I'll do my best to help you. And in the end I like to make a mave-scm howto webpagewith all of this.Good luck,Torbjørn

Re: plugin testing

[Jesse McConnell]

I reread through some of this thread this morning which prompted me poke
around the ReflectionUtils classin plexus-utils and added some functionality
to it as well as the AbstractMojoTestCase..


the test cases extending the harness now have the ability to get and set
values on the mojo and internal variables using reflectionutils...this
should address concerns about wanting to be able to do testing entirely in
java, using the plugin configuration xml route, or a combination of both.

I added example test cases to the simple mojo test that comes with the
harness and added a test class to plexus utils to test all that
functionality and it all seems to be a go.

http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Harness

I also updated the documentation at the link above so people can see how to
use this new mechanism (and a couple of warnings :)

with this ability to now mine the state of the mojo and its internals with
impunity I am getting pretty happy with the way the harness is shaping up in
terms of actually being useful...now I just need some more people to give it
a spin and adjust accordingly.

feedback on both the usage of the harness and perhaps
issues/concerns/comments on the guide linked above would be much
appreciated!

cheers,
jesse


p.s. I might actually let this thread die someday :P


On 3/14/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
>
> its back, the thread from heck and gone...
>
> ok, so now that we have a moderately working plugin harness that I have
> been able to get working for a few plugins, what should be the next step on
> this?
>
> Talking it over with jdcasey we both loathe the idea of just moving the
> plugin harness directly over to the plugin trunk.  One idea that we both
> kinda liked was pulling a branch and further developing the plugin harness
> and the test cases for each plugin there and then when we are happy just
> doing a wholesale merge to the trunk.  This shouldn't be bad as I'll
> illustrate next :)
>
> The nature of the harness means that having to modify the actual plugin
> source in any way is an indication that we missed something (IMO at least)
> so we shouldn't have to worry about breaking plugins at least up to the test
> phase...Adding tests to the plugin should only be a matter of preparing a
> *MojoTest and the various plugin-pom.xml files for each test case in a
> directory structure.
>
> For the examples I was working with I did:
>
> src/test/resources/unit/-test/plugin-pom.xml
>
> then in the test case when I looked up my mojo I used the location that
> the file would have been copied to in:
>
> target/test-classes/unit/-test/plugin-pom.xml
>
> an other files that were needed were nested below the plugin-pom.xml in
> src/main/foo or whatever.
>
> so...any ideas on how this ought to go from here?
>
> oh, and the jira issue on this and related confluence documentation is:
>
> http://jira.codehaus.org/browse/MNG-32
>
> http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Harness
>
>
> Jesse
>
>
>
> On 3/7/06, Vincent Massol < [EMAIL PROTECTED]> wrote:
>
> > +1 to all that! Exactly my sentiment.
> >
> > Thanks
> > -Vincent
> >
> > > -Original Message-
> > > From: Brett Porter [mailto:[EMAIL PROTECTED]
> > > Sent: mardi 7 mars 2006 22:37
> > > To: Maven Developers List
> > > Subject: Re: plugin testing
> > >
> > > Summarising this thread...
> > >
> > > Terminology I mean when I mention things:
> > > - unit testing, intended to test this module only, independent of its
> > > interaction with Maven and dependencies
> > > - integration testing, in this context, is intended to test that the
> > > plugin works in Maven, that it's metadata is bound correctly,
> > lifecycle
> > > interactions, etc. Done via the embedder.
> > >
> > > I saw this as being the unit testing side, and the reason we needed
> > > stubs is because we weren't using real objects.
> > >
> > > It sounds like what we have now is just great as it is, and I'd like
> > to
> > > start with that and see how far we get. My only issue remains the
> > > confusing POM-that-isn't-a-POM that you were going to fix anyway.
> > >
> > > I was concerned with the perceived direction towards using more real
> > > Maven stuff. I think there are several levels to this:
> > >
> > > * artifact code. I think it's quite reasonable to use this via
> > > maven-artifact as it is fairly pojo like anyway. No new stubs needed.
> > >
> > > * project builder. If you need a whole pom with interpolation and
> > > inheritance, you build up a local repo and use the project builder. I
> > > think this indicates a smell in the mojo (see more details below), but
> > > we might have to live with it in the current setup. The framework
> > > shouldn't care - it just takes in a MavenProject, and someone has
> > > already either instantiated a stub, or built with the project builder
> > > component. Still, we should start to consider the embedder here.
> > >
> > > * artifact code that sets up the whole environment through