Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Carlos Sanchez]

+1

On 11/29/06, John Tolentino <[EMAIL PROTECTED]> wrote:

+1

On 11/30/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
> I like it, nice way to solve the problem I think.  I notice the
> javadoc plugin also addresses a problem I had with it a couple of
> months ago so I am all for releasing it.
>
> +1
>
> jesse
>
> On 11/29/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> > I have fixed all the headers and checked them in.
> >
> > jason.
> >
> > On 29 Nov 06, at 6:54 PM 29 Nov 06, Joakim Erdfelt wrote:
> >
> > > Once the headers are fixed, +1
> > >
> > > - Joakim
> > >
> > > Daniel Kulp wrote:
> > >> Jason,
> > >>
> > >> The files still don't have the proper Apache header on them.  You
> > >> added
> > >> the old style (with the copyright date) instead of the new style
> > >> documented at:
> > >> http://www.apache.org/legal/src-headers.html
> > >> Those need to change.
> > >>
> > >> Also, the pom.xml files need to have the header as well.   Note:
> > >> there is
> > >> a bug in maven/jdom that may discard the header at deploy time.
> > >> Thus,
> > >> it may need to go INSIDE the  tag.
> > >>
> > >> The other files in "src" also need it (fml/faq.fml for example,
> > >> possibly
> > >> the properties files as well).
> > >>
> > >> Dan
> > >>
> > >>
> > >> On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> This is a group release to attempt to deal with the licensing
> > >>> resources that need to be packaged up in all the archives we
> > >>> distribute. This is, in particular, and attempt to deal with the
> > >>> JARs
> > >>> we release. Namely the binary, source, and javadoc JARs we create
> > >>> with the JAR, Source, and JavaDoc plugins respectively.
> > >>>
> > >>> I have created the Remote Resources Plugin which is documented here:
> > >>>
> > >>> http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/
> > >>>
> > >>> And I have created a diagram of the process that is currently
> > >>> happening as a result of the changes I have made to the Source, and
> > >>> JavaDoc plugins:
> > >>>
> > >>> http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png
> > >>>
> > >>> Essentially the remote resources plugins creates a directory of
> > >>> resources and modifies the POM at runtime so it carries with it the
> > >>> information about this directory. The other archiving plugins then
> > >>> look for this resource and insert it into the archives they
> > >>> create if
> > >>> found. Ideally the Resource element should have a unique id but the
> > >>> directory name will do for now.
> > >>>
> > >>> You can see here that I've created a profile which will enable the
> > >>> remote resources plugins and pull down the bundle that contains the
> > >>> standard license and notice files:
> > >>>
> > >>> http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
> > >>>
> > >>> And I have deployed all the plugins above with this tool chain so
> > >>> you
> > >>> can see them here:
> > >>>
> > >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> > >>> maven/
> > >>> plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
> > >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> > >>> maven/
> > >>> plugins/maven-source-plugin/2.0.2-SNAPSHOT/
> > >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> > >>> maven/
> > >>> plugins/maven-javadoc-plugin/2.2-SNAPSHOT/
> > >>>
> > >>> If I can release these plugins then I think we can solve most of the
> > >>> licensing/resource doldrums.
> > >>>
> > >>> Jason.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 
> > >>> -
> > >>> 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]
> >
> >
>
>
> --
> jesse mcconnell
> [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]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[John Tolentino]

+1

On 11/30/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:

I like it, nice way to solve the problem I think.  I notice the
javadoc plugin also addresses a problem I had with it a couple of
months ago so I am all for releasing it.

+1

jesse

On 11/29/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> I have fixed all the headers and checked them in.
>
> jason.
>
> On 29 Nov 06, at 6:54 PM 29 Nov 06, Joakim Erdfelt wrote:
>
> > Once the headers are fixed, +1
> >
> > - Joakim
> >
> > Daniel Kulp wrote:
> >> Jason,
> >>
> >> The files still don't have the proper Apache header on them.  You
> >> added
> >> the old style (with the copyright date) instead of the new style
> >> documented at:
> >> http://www.apache.org/legal/src-headers.html
> >> Those need to change.
> >>
> >> Also, the pom.xml files need to have the header as well.   Note:
> >> there is
> >> a bug in maven/jdom that may discard the header at deploy time.
> >> Thus,
> >> it may need to go INSIDE the  tag.
> >>
> >> The other files in "src" also need it (fml/faq.fml for example,
> >> possibly
> >> the properties files as well).
> >>
> >> Dan
> >>
> >>
> >> On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:
> >>
> >>> Hi,
> >>>
> >>> This is a group release to attempt to deal with the licensing
> >>> resources that need to be packaged up in all the archives we
> >>> distribute. This is, in particular, and attempt to deal with the
> >>> JARs
> >>> we release. Namely the binary, source, and javadoc JARs we create
> >>> with the JAR, Source, and JavaDoc plugins respectively.
> >>>
> >>> I have created the Remote Resources Plugin which is documented here:
> >>>
> >>> http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/
> >>>
> >>> And I have created a diagram of the process that is currently
> >>> happening as a result of the changes I have made to the Source, and
> >>> JavaDoc plugins:
> >>>
> >>> http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png
> >>>
> >>> Essentially the remote resources plugins creates a directory of
> >>> resources and modifies the POM at runtime so it carries with it the
> >>> information about this directory. The other archiving plugins then
> >>> look for this resource and insert it into the archives they
> >>> create if
> >>> found. Ideally the Resource element should have a unique id but the
> >>> directory name will do for now.
> >>>
> >>> You can see here that I've created a profile which will enable the
> >>> remote resources plugins and pull down the bundle that contains the
> >>> standard license and notice files:
> >>>
> >>> http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
> >>>
> >>> And I have deployed all the plugins above with this tool chain so
> >>> you
> >>> can see them here:
> >>>
> >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> >>> maven/
> >>> plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
> >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> >>> maven/
> >>> plugins/maven-source-plugin/2.0.2-SNAPSHOT/
> >>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> >>> maven/
> >>> plugins/maven-javadoc-plugin/2.2-SNAPSHOT/
> >>>
> >>> If I can release these plugins then I think we can solve most of the
> >>> licensing/resource doldrums.
> >>>
> >>> Jason.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>> -
> >>> 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]
>
>


--
jesse mcconnell
[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: Flag to set all snapshot repos to updatePolicy = never?

[Jason Dillon]

From what I can tell this mail is talking about putting the assemble  
in the top-level pom, not in the maven-cli pom.


In Geronimo we hook up assembly:attached to be executed by default  
when `mvn install` is run with no problems.  The result is, there is  
one command to build modules and generate the assembly zips.


It looks like the maven-cli module executes last anyways, so hooking  
up assemble:attached should not cause any problems... only reduces  
the steps to build the assembly.


--jason


On Nov 29, 2006, at 7:41 PM, Wendy Smoak wrote:


On 11/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Why is this step needed:


cd maven-cli
mvn assembly:assembly


Why not hook up assembly to the be performed with just `mvn  
install` ?


Possibly because of what John Casey describes here:
http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level- 
project-directory-p4735063.html


--
Wendy

-
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: svn commit: r480817 - in /maven/archiva/trunk: archiva-indexer/src/main/java/org/apache/maven/archiva/indexer/record/ archiva-reports-standard/src/main/java/org/apache/maven/archiva/reporting/ arc

[Brett Porter]

All of these are meant to indicate programming errors - the RT  
exceptions should be guarded by checking the validity of the POM used  
to create the artifacts. As for the illegalstateexception - how is  
the reports module getting handed a file that doesn't exist to report  
on?


- Brett

On 30/11/2006, at 2:32 PM, [EMAIL PROTECTED] wrote:


Author: joakime
Date: Wed Nov 29 19:32:08 2006
New Revision: 480817

URL: http://svn.apache.org/viewvc?view=rev&rev=480817
Log:
* Correcting LocationArtifactReportProcessor to not throw  
IllegalStateException as it halts the discovery and indexing.
* Catching InvalidArtifactRTException in DefaultReportExecutor to  
allow discovery and indexing to proceed to next artifact unhindered.
* Catching InvalidArtifactRTException in  
StandardArtifactIndexRecordFactory to allow discovery and indexeing  
to proceed to next artifact unhindered.



Modified:
maven/archiva/trunk/archiva-indexer/src/main/java/org/apache/ 
maven/archiva/indexer/record/StandardArtifactIndexRecordFactory.java
maven/archiva/trunk/archiva-reports-standard/src/main/java/org/ 
apache/maven/archiva/reporting/DefaultReportExecutor.java
maven/archiva/trunk/archiva-reports-standard/src/main/java/org/ 
apache/maven/archiva/reporting/LocationArtifactReportProcessor.java
maven/archiva/trunk/archiva-reports-standard/src/test/java/org/ 
apache/maven/archiva/reporting/ 
LocationArtifactReportProcessorTest.java


Modified: maven/archiva/trunk/archiva-indexer/src/main/java/org/ 
apache/maven/archiva/indexer/record/ 
StandardArtifactIndexRecordFactory.java
URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva- 
indexer/src/main/java/org/apache/maven/archiva/indexer/record/ 
StandardArtifactIndexRecordFactory.java? 
view=diff&rev=480817&r1=480816&r2=480817
== 

--- maven/archiva/trunk/archiva-indexer/src/main/java/org/apache/ 
maven/archiva/indexer/record/ 
StandardArtifactIndexRecordFactory.java (original)
+++ maven/archiva/trunk/archiva-indexer/src/main/java/org/apache/ 
maven/archiva/indexer/record/ 
StandardArtifactIndexRecordFactory.java Wed Nov 29 19:32:08 2006

@@ -18,6 +18,7 @@

 import org.apache.maven.archiva.indexer.RepositoryIndexException;
 import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.InvalidArtifactRTException;
 import org.apache.maven.artifact.factory.ArtifactFactory;
 import org.apache.maven.artifact.repository.ArtifactRepository;
 import org.apache.maven.model.Dependency;
@@ -251,8 +252,17 @@
 {
 // TODO: this can create a -SNAPSHOT.pom when it didn't  
exist and a timestamped one did. This is harmless, but should be  
avoided

 // TODO: will this pollute with local repo metadata?
-MavenProject project = projectBuilder.buildFromRepository 
( artifact, Collections.EMPTY_LIST, repository );

-return project.getModel();
+
+try
+{
+MavenProject project =  
projectBuilder.buildFromRepository( artifact,  
Collections.EMPTY_LIST, repository );

+return project.getModel();
+}
+catch ( InvalidArtifactRTException e )
+{
+throw new ProjectBuildingException( artifact.getId(),  
"Unable to build project from invalid artifact ["

++ artifact + "]", e );
+}
 }

 private void populateArchiveEntries( List files,  
StandardArtifactIndexRecord record, File artifactFile )


Modified: maven/archiva/trunk/archiva-reports-standard/src/main/ 
java/org/apache/maven/archiva/reporting/DefaultReportExecutor.java
URL: http://svn.apache.org/viewvc/maven/archiva/trunk/archiva- 
reports-standard/src/main/java/org/apache/maven/archiva/reporting/ 
DefaultReportExecutor.java?view=diff&rev=480817&r1=480816&r2=480817
== 

--- maven/archiva/trunk/archiva-reports-standard/src/main/java/org/ 
apache/maven/archiva/reporting/DefaultReportExecutor.java (original)
+++ maven/archiva/trunk/archiva-reports-standard/src/main/java/org/ 
apache/maven/archiva/reporting/DefaultReportExecutor.java Wed Nov  
29 19:32:08 2006

@@ -21,6 +21,7 @@
 import org.apache.maven.archiva.discoverer.MetadataDiscoverer;
 import  
org.apache.maven.archiva.discoverer.filter.AcceptAllMetadataFilter;

 import org.apache.maven.artifact.Artifact;
+import org.apache.maven.artifact.InvalidArtifactRTException;
 import org.apache.maven.artifact.factory.ArtifactFactory;
 import org.apache.maven.artifact.repository.ArtifactRepository;
 import  
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout;

@@ -115,6 +116,10 @@
 projectBuilder.buildFromRepository 
( pomArtifact, Collections.EMPTY_LIST, repository );


 model = project.getModel();
+}
+catch ( InvalidArtifactRTException e )
+{
+reporter.addWarning( artifact, null, null,  
"In

Re: Flag to set all snapshot repos to updatePolicy = never?

[Brett Porter]

But we should be able to use the :single goal like we do for  
maven-2.0.x until the other lifecycle things are sorted out.


- Brett

On 30/11/2006, at 2:41 PM, Wendy Smoak wrote:


On 11/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Why is this step needed:


cd maven-cli
mvn assembly:assembly


Why not hook up assembly to the be performed with just `mvn  
install` ?


Possibly because of what John Casey describes here:
http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level- 
project-directory-p4735063.html


--
Wendy

-
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: Flag to set all snapshot repos to updatePolicy = never?

[Wendy Smoak]

On 11/28/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Why is this step needed:


cd maven-cli
mvn assembly:assembly


Why not hook up assembly to the be performed with just `mvn install` ?


Possibly because of what John Casey describes here:
http://www.nabble.com/Re%3A-building-assemblies-from-the-top-level-project-directory-p4735063.html

--
Wendy

-
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 (15 issues)
Subscriber: mavendevlist


Key Summary
MAVENUPLOAD-1257Please upload EZMorph-0.9.1
http://jira.codehaus.org/browse/MAVENUPLOAD-1257
MAVENUPLOAD-1250Upload org.hibernate:hibernate:jar:3.2.1.ga to ibiblio
http://jira.codehaus.org/browse/MAVENUPLOAD-1250
MAVENUPLOAD-1242JFreeChart 1.0.3
http://jira.codehaus.org/browse/MAVENUPLOAD-1242
MAVENUPLOAD-1243JCommon 1.0.6
http://jira.codehaus.org/browse/MAVENUPLOAD-1243
MAVENUPLOAD-1149Upload jboss-seam-ui-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1149
MAVENUPLOAD-1148Upload jboss-seam-debug-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1148
MAVENUPLOAD-1147Upload jboss-seam-1.0.1.jar
http://jira.codehaus.org/browse/MAVENUPLOAD-1147
MAVENUPLOAD-1130Rhino js-1.5R4.1
http://jira.codehaus.org/browse/MAVENUPLOAD-1130
MAVENUPLOAD-1128Rhino js-1.5R3
http://jira.codehaus.org/browse/MAVENUPLOAD-1128
MAVENUPLOAD-1129Rhino js-1.5R4-RC3
http://jira.codehaus.org/browse/MAVENUPLOAD-1129
MAVENUPLOAD-1084Upload drools:drools-core:3.0.4 to ibiblio
http://jira.codehaus.org/browse/MAVENUPLOAD-1084
MAVENUPLOAD-1088Upload drools:drools-decisiontables:3.0.4 to ibiblio
http://jira.codehaus.org/browse/MAVENUPLOAD-1088
MAVENUPLOAD-1085Upload drools:drools-compiler:3.0.4 to ibiblio
http://jira.codehaus.org/browse/MAVENUPLOAD-1085
MAVENUPLOAD-1087Upload drools:drools-jsr94:3.0.4 to ibiblio
http://jira.codehaus.org/browse/MAVENUPLOAD-1087
MAVENUPLOAD-976Please upload SUN Java 1.2 rutime 
http://jira.codehaus.org/browse/MAVENUPLOAD-976


-
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 (34 issues)
Subscriber: mavendevlist


Key Summary
MEV-461 Missing pom for commons-logging-api-1.1
http://jira.codehaus.org/browse/MEV-461
MEV-459 Velocity should not depend on Velocity-dep
http://jira.codehaus.org/browse/MEV-459
MEV-457 Geronimo jar fails to download
http://jira.codehaus.org/browse/MEV-457
MEV-455 bad checksums on repo1.maven.org
http://jira.codehaus.org/browse/MEV-455
MEV-454 testng-spring has a invalid dependency on testng.
http://jira.codehaus.org/browse/MEV-454
MEV-443 Several projects have maven-metadata.xml files that are missing 
released versions
http://jira.codehaus.org/browse/MEV-443
MEV-450 plexus-velocity 1.1.2 includes invalid external snapshot 
repositories
http://jira.codehaus.org/browse/MEV-450
MEV-449 lucene 1.9.1 JAR is hosed.
http://jira.codehaus.org/browse/MEV-449
MEV-448 xmlrpc POM should include commons-codec
http://jira.codehaus.org/browse/MEV-448
MEV-441 Several projects have bad maven-metadata.xml files that are 
screwing up dependencies with version range feature
http://jira.codehaus.org/browse/MEV-441
MEV-20  clean up bad IDs in the repository
http://jira.codehaus.org/browse/MEV-20
MEV-436 JOTM 2.0.10 incorrectly specifies javax.resource/connector-1.0 it 
needs connector-1.5.
http://jira.codehaus.org/browse/MEV-436
MEV-427 relocate ehcache:ehcache to net.sf.ehcache
http://jira.codehaus.org/browse/MEV-427
MEV-296 Activemq-core (and other activemq projects) 3.2.1 have unexpanded 
variables
http://jira.codehaus.org/browse/MEV-296
MEV-405 pom for cactus:cactus:13-1.7.2
http://jira.codehaus.org/browse/MEV-405
MEV-404 pom for cactus:cactus-ant:13-1.7.2
http://jira.codehaus.org/browse/MEV-404
MEV-401 Incoherences / duplication between javax.xml and com.sun.xml
http://jira.codehaus.org/browse/MEV-401
MEV-334 Stax POM points to an invalid XMLBeans dependency
http://jira.codehaus.org/browse/MEV-334
MEV-384 velocity 1.4 dependencies are wrong
http://jira.codehaus.org/browse/MEV-384
MEV-375 Relocate xpp to xpp3
http://jira.codehaus.org/browse/MEV-375
MEV-364 Fix dependencies of common-lang 1.0 (add test scope for junit)
http://jira.codehaus.org/browse/MEV-364
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-351 xmlc-xerces-2.2.7.1.jar is unnecessary and  xmlc-apis.jar is 
required.
http://jira.codehaus.org/browse/MEV-351
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-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


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

Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Jesse McConnell]

I like it, nice way to solve the problem I think.  I notice the
javadoc plugin also addresses a problem I had with it a couple of
months ago so I am all for releasing it.

+1

jesse

On 11/29/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:

I have fixed all the headers and checked them in.

jason.

On 29 Nov 06, at 6:54 PM 29 Nov 06, Joakim Erdfelt wrote:

> Once the headers are fixed, +1
>
> - Joakim
>
> Daniel Kulp wrote:
>> Jason,
>>
>> The files still don't have the proper Apache header on them.  You
>> added
>> the old style (with the copyright date) instead of the new style
>> documented at:
>> http://www.apache.org/legal/src-headers.html
>> Those need to change.
>>
>> Also, the pom.xml files need to have the header as well.   Note:
>> there is
>> a bug in maven/jdom that may discard the header at deploy time.
>> Thus,
>> it may need to go INSIDE the  tag.
>>
>> The other files in "src" also need it (fml/faq.fml for example,
>> possibly
>> the properties files as well).
>>
>> Dan
>>
>>
>> On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:
>>
>>> Hi,
>>>
>>> This is a group release to attempt to deal with the licensing
>>> resources that need to be packaged up in all the archives we
>>> distribute. This is, in particular, and attempt to deal with the
>>> JARs
>>> we release. Namely the binary, source, and javadoc JARs we create
>>> with the JAR, Source, and JavaDoc plugins respectively.
>>>
>>> I have created the Remote Resources Plugin which is documented here:
>>>
>>> http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/
>>>
>>> And I have created a diagram of the process that is currently
>>> happening as a result of the changes I have made to the Source, and
>>> JavaDoc plugins:
>>>
>>> http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png
>>>
>>> Essentially the remote resources plugins creates a directory of
>>> resources and modifies the POM at runtime so it carries with it the
>>> information about this directory. The other archiving plugins then
>>> look for this resource and insert it into the archives they
>>> create if
>>> found. Ideally the Resource element should have a unique id but the
>>> directory name will do for now.
>>>
>>> You can see here that I've created a profile which will enable the
>>> remote resources plugins and pull down the bundle that contains the
>>> standard license and notice files:
>>>
>>> http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
>>>
>>> And I have deployed all the plugins above with this tool chain so
>>> you
>>> can see them here:
>>>
>>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>>> maven/
>>> plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
>>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>>> maven/
>>> plugins/maven-source-plugin/2.0.2-SNAPSHOT/
>>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>>> maven/
>>> plugins/maven-javadoc-plugin/2.2-SNAPSHOT/
>>>
>>> If I can release these plugins then I think we can solve most of the
>>> licensing/resource doldrums.
>>>
>>> Jason.
>>>
>>>
>>>
>>>
>>>
>>> 
>>> -
>>> 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]





--
jesse mcconnell
[EMAIL PROTECTED]

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

Re: [vote] Archiva Logo

[Joakim Erdfelt]

I am abstaining from this vote.  +0

- Joakim

Brett Porter wrote:
> Hi,
>
> There seemed to be no major objections to the logos presented, so I'll
> turn this into a formal vote.
>
> Please vote [1] for the one you would like and [2] for your second
> preference, if you have one, and so on.
>
> Ideally, there will be a clear majority of first preferences. The
> lowest scoring choice will be eliminated and their second preference
> used, and so on to determine the most popular.
>
> http://people.apache.org/~brett/archiva_logo.gif
> Vote will close in 72 hours.
>
> [ ] Top Left
> [ ] Top Right
> [ ] Lower Left
> [ ] Lower Right
>
> I will count the feedback from these people already: Raphael (1 -
> Lower Left), Wendell (1 - Lower Left), Milos (1 - Lower Left, 2 -
> Lower Right), Henri (1 - Lower Left), Natalie (1 - Top Right), Jesse
> (1 - Top Right), Edwin (1 Top Right), Nicolas (1 - Lower Left).
>
> If you want to change your vote, just respond again.
>
> Cheers,
> Brett
>

Re: Plugin Releases

[Jason van Zyl]

Now that thing are working I suggest we start new threads for all the  
votes.


Jason.

On 29 Nov 06, at 7:29 PM 29 Nov 06, Jason van Zyl wrote:


Hi,

The license insertion in to JAR, Source, and JavaDoc bundles is  
working fine now and I have updated the headers to their correct  
form for all resoures for the following Plugins:


Dependency
Checkstyle
JavaDoc
PMD
RAR
RAR
Release
Remote Resources
Source
Surefire
WAR

Anyone who has been working on these can now release when you're  
ready as the licensing is taken care of and the headers are correct.


Jason.

-
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]

Plugin Releases

[Jason van Zyl]

Hi,

The license insertion in to JAR, Source, and JavaDoc bundles is  
working fine now and I have updated the headers to their correct form  
for all resoures for the following Plugins:


Dependency
Checkstyle
JavaDoc
PMD
RAR
RAR
Release
Remote Resources
Source
Surefire
WAR

Anyone who has been working on these can now release when you're  
ready as the licensing is taken care of and the headers are correct.


Jason.

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

Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Jason van Zyl]

I have fixed all the headers and checked them in.

jason.

On 29 Nov 06, at 6:54 PM 29 Nov 06, Joakim Erdfelt wrote:


Once the headers are fixed, +1

- Joakim

Daniel Kulp wrote:

Jason,

The files still don't have the proper Apache header on them.  You  
added

the old style (with the copyright date) instead of the new style
documented at:
http://www.apache.org/legal/src-headers.html
Those need to change.

Also, the pom.xml files need to have the header as well.   Note:  
there is
a bug in maven/jdom that may discard the header at deploy time.
Thus,

it may need to go INSIDE the  tag.

The other files in "src" also need it (fml/faq.fml for example,  
possibly

the properties files as well).

Dan


On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:


Hi,

This is a group release to attempt to deal with the licensing
resources that need to be packaged up in all the archives we
distribute. This is, in particular, and attempt to deal with the  
JARs

we release. Namely the binary, source, and javadoc JARs we create
with the JAR, Source, and JavaDoc plugins respectively.

I have created the Remote Resources Plugin which is documented here:

http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/

And I have created a diagram of the process that is currently
happening as a result of the changes I have made to the Source, and
JavaDoc plugins:

http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png

Essentially the remote resources plugins creates a directory of
resources and modifies the POM at runtime so it carries with it the
information about this directory. The other archiving plugins then
look for this resource and insert it into the archives they  
create if

found. Ideally the Resource element should have a unique id but the
directory name will do for now.

You can see here that I've created a profile which will enable the
remote resources plugins and pull down the bundle that contains the
standard license and notice files:

http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml

And I have deployed all the plugins above with this tool chain so  
you

can see them here:

http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
maven/

plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
maven/

plugins/maven-source-plugin/2.0.2-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/ 
maven/

plugins/maven-javadoc-plugin/2.2-SNAPSHOT/

If I can release these plugins then I think we can solve most of the
licensing/resource doldrums.

Jason.





 
-

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: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Joakim Erdfelt]

Once the headers are fixed, +1

- Joakim

Daniel Kulp wrote:
> Jason,
>
> The files still don't have the proper Apache header on them.  You added 
> the old style (with the copyright date) instead of the new style 
> documented at:
> http://www.apache.org/legal/src-headers.html
> Those need to change.
>
> Also, the pom.xml files need to have the header as well.   Note: there is 
> a bug in maven/jdom that may discard the header at deploy time.   Thus, 
> it may need to go INSIDE the  tag.
>
> The other files in "src" also need it (fml/faq.fml for example, possibly 
> the properties files as well).
>
> Dan
>
>
> On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:
>   
>> Hi,
>>
>> This is a group release to attempt to deal with the licensing
>> resources that need to be packaged up in all the archives we
>> distribute. This is, in particular, and attempt to deal with the JARs
>> we release. Namely the binary, source, and javadoc JARs we create
>> with the JAR, Source, and JavaDoc plugins respectively.
>>
>> I have created the Remote Resources Plugin which is documented here:
>>
>> http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/
>>
>> And I have created a diagram of the process that is currently
>> happening as a result of the changes I have made to the Source, and
>> JavaDoc plugins:
>>
>> http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png
>>
>> Essentially the remote resources plugins creates a directory of
>> resources and modifies the POM at runtime so it carries with it the
>> information about this directory. The other archiving plugins then
>> look for this resource and insert it into the archives they create if
>> found. Ideally the Resource element should have a unique id but the
>> directory name will do for now.
>>
>> You can see here that I've created a profile which will enable the
>> remote resources plugins and pull down the bundle that contains the
>> standard license and notice files:
>>
>> http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
>>
>> And I have deployed all the plugins above with this tool chain so you
>> can see them here:
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
>> plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
>> plugins/maven-source-plugin/2.0.2-SNAPSHOT/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
>> plugins/maven-javadoc-plugin/2.2-SNAPSHOT/
>>
>> If I can release these plugins then I think we can solve most of the
>> licensing/resource doldrums.
>>
>> Jason.
>>
>>
>>
>>
>>
>> -
>> 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: Ibiblio repository broken for Maven 1.0.2

[Carlos Sanchez]

Yep, I know Jason did the change today

On 11/29/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:

Hi,

On 11/30/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> You should be able to use a mirror while this gets fixed
> http://maven.apache.org/guides/mini/guide-mirror-settings.html

Yeah, I had no trouble setting myself up. I just wanted to let you
know that the mirrors.ibiblio.org redirect probably breaks the huge
installed base of Maven 1.0.2.

BR,

Jukka Zitting

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Ibiblio repository broken for Maven 1.0.2

[Jukka Zitting]

Hi,

On 11/30/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

You should be able to use a mirror while this gets fixed
http://maven.apache.org/guides/mini/guide-mirror-settings.html


Yeah, I had no trouble setting myself up. I just wanted to let you
know that the mirrors.ibiblio.org redirect probably breaks the huge
installed base of Maven 1.0.2.

BR,

Jukka Zitting

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

Re: Ibiblio repository broken for Maven 1.0.2

[Carlos Sanchez]

You should be able to use a mirror while this gets fixed
http://maven.apache.org/guides/mini/guide-mirror-settings.html


On 11/29/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:

Hi,

On 11/30/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> It seems that the mirrors.ibiblio.org redirect doesn't work well with
> Maven 1.0.2. I just tried to download a new dependency from the
> repository using 1.0.2, but apparently the 301 redirect is treated as
> an error code.

Note that the problem is not related to the incorrect Derby version
number in the example I posted, the following fails as well.


 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download derby-10.2.1.6.jar.
Error retrieving artifact from
[http://www.ibiblio.org/maven/org.apache.derby/jars/derby-10.2.1.6.jar]:
java.io.IOException: Unknown error downloading; status code was: 301
WARNING: Failed to download derby-10.2.1.6.jar.
The build cannot continue because of the following unsatisfied dependency:

derby-10.2.1.6.jar (try downloading from http://db.apache.org/derby/)

Total time: 3 seconds
Finished at: Thu Nov 30 00:42:40 EET 2006


BR,

Jukka Zitting

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Ibiblio repository broken for Maven 1.0.2

[Jukka Zitting]

Hi,

On 11/30/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:

It seems that the mirrors.ibiblio.org redirect doesn't work well with
Maven 1.0.2. I just tried to download a new dependency from the
repository using 1.0.2, but apparently the 301 redirect is treated as
an error code.


Note that the problem is not related to the incorrect Derby version
number in the example I posted, the following fails as well.


__  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download derby-10.2.1.6.jar.
Error retrieving artifact from
[http://www.ibiblio.org/maven/org.apache.derby/jars/derby-10.2.1.6.jar]:
java.io.IOException: Unknown error downloading; status code was: 301
WARNING: Failed to download derby-10.2.1.6.jar.
The build cannot continue because of the following unsatisfied dependency:

derby-10.2.1.6.jar (try downloading from http://db.apache.org/derby/)

Total time: 3 seconds
Finished at: Thu Nov 30 00:42:40 EET 2006


BR,

Jukka Zitting

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

Ibiblio repository broken for Maven 1.0.2

[Jukka Zitting]

Hi,

It seems that the mirrors.ibiblio.org redirect doesn't work well with
Maven 1.0.2. I just tried to download a new dependency from the
repository using 1.0.2, but apparently the 301 redirect is treated as
an error code. See below:


__  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download derby-10.2.6.1.jar.
Error retrieving artifact from
[http://www.ibiblio.org/maven/org.apache.derby/jars/derby-10.2.6.1.jar]:
java.io.IOException: Unknown error downloading; status code was: 301
WARNING: Failed to download derby-10.2.6.1.jar.
The build cannot continue because of the following unsatisfied dependency:

derby-10.2.6.1.jar (try downloading from http://db.apache.org/derby/)

Total time: 14 seconds
Finished at: Thu Nov 30 00:28:57 EET 2006


BR,

Jukka Zitting

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

Re: cyclic dependency in plugins

[Brett Porter]

On 30/11/2006, at 1:11 AM, Jason van Zyl wrote:



On 29 Nov 06, at 1:35 AM 29 Nov 06, Brett Porter wrote:

You're oversimplifying it. There is no cycle when you run mvn  
install, Maven is misdetecting it.




I cannot even run "mvn clean" in the plugins directory so I'm not  
sure what you're talking about. Try it.


I have tried it, and know it is broken.

Maven is misdetecting a cycle in the reactor dependency logic which  
happens right at the start, before any plugin stuff comes in, so it  
affects everything.


There is no logical cycle in there, as explained below.



When you generate a site, if you are to do "install site" on both  
without having a working version of either first, then javadoc ->  
checkstyle ->javadoc is never going to be a cycle you can fix.  
You'd need to install both first, then build the site for both to  
make it work.


The reporting dependencies need to only be assessed when you are  
generating the site, not building the plugin. Then, it isn't a  
problem because you can mvn install without any cycle, and mvn  
site has no cycle because the things are already built so the  
order isn't important.


What's more, versions need to be honoured. We should be able to  
use the last javadoc release (and so no dependency in the reactor)  
for the reporting, while building trunk.


Two relatively simple things to fix. The only workaround is to  
remove the reporting plugins from the pom altogether (copying it  
to every plugin will only work if you leave some of them out, eg  
no javadoc on checkstyle).


- Brett

On 29/11/2006, at 4:32 PM, Jason van Zyl wrote:


On 28 Nov 06, at 5:25 PM 28 Nov 06, Brett Porter wrote:


It's filed in JIRA. I think we need to fix Maven.



To allow cycles? I mean the second that cycle was introduced it  
made working with the plugins pretty crappy. How about fixing the  
cycle?


The only way to fix this is to disable the reporting, or copy it  
into every plugin - not really desirable either.


Or fix the cycle??




-
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]

Accessing compiler-plugin configuration from another plugin

[Dietrich Schulten]

Hi,

I am cooperating with Frank Seidinger on the J2ME plugin, and we need to
set the bootclasspath of the compiler plugin. This can be done in the
POM like this:



   
...



However, I want to use the Unified Emulator Interface to determine the
bootclasspath automatically and configure the compiler accordingly. I am
able to access the UEI from my Mojo, but I do not know how to access the
compiler plugin configuration programmatically. I think I need the
current container and an evaluator to do this, at least that is how the
test harness configures plugins:

ComponentConfigurator configurator = (ComponentConfigurator)
getContainer().lookup( ComponentConfigurator.ROLE );
   
XmlPlexusConfiguration plexusConfiguration = new
XmlPlexusConfiguration("configuration")
// add configuration items

configurator.configureComponent( mojo, plexusConfiguration, evaluator,
getContainer().getContainerRealm() );

The test harness creates its own container, and it uses a stub as
evaluator. How do I get the container of a running maven instance and
which evaluator do I have to pass to configureComponent()?

An alternative:
Frank proposes to introduce the Wireless toolkits on the plexus compiler
level. Where can we find more information about this and what would be
more appropriate from your point of view?

Regards,
Dietrich

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

Re: moving maven repository to mirrors.ibiblio.org (fwd)

[Jason van Zyl]

On 29 Nov 06, at 11:22 AM 29 Nov 06, Don Sizemore wrote:



|Is mirrors.ibiblio.org balancing the load on the mirrors? Will you  
leave
|www.ibiblio.org/maven and www.ibiblio.org/maven2 as redirects to  
the new
|location? We need to check for maven1 users that still point  
there, but

|for maven2 is fine as they already use repo1.maven.org as central

  Hi Carlos,

  I've copied the maven and maven2 repositories into their new  
locations

on mirrors.ibiblio.org, and have created rsync modules on that server.
We'll leave the old content in their old locations for a while.  I  
think

we need three things to happen:

 1) The maven folks (Brett?) update their 4-hourly rsync script to  
update
/export/mirrors/maven and /export/mirrors/maven2 instead of /public/ 
html




I have updated the scripts. So we now use mirrors.ibiblio.org and  
have you copied our keys over?


 2) do we need to update the .htaccess files, which expect a  
RewriteBase
of /maven, which will become /pub/mirrors/maven on  
mirrors.ibiblio.org.

Or we could simply throw a symlink on mirrors.ibiblio if you have one
.htaccess file that you push out to all of your mirrors?



I will take a look and let you know. Ideally we would like to mirror  
this content and not have to burden the mirror providers with having  
to change much if anything.



 3) We need to update this page to point to the new location:
http://maven.apache.org/guides/mini/guide-mirror-settings.html
(note that ggi-project.org and ibiblio.net are both on ibiblio.org)



Updated.

 3.5) Maybe send out a note to some of the Maven lists noting the  
change

in repositories?  Or is that overkill



Starting with the next release of Maven 1.x we will be able to  
control the default repositories and their use from Maven itself.  
Folks should not have to update any configuration.



  thank you,919.962.5646 w
  donald sizemore, ii   919.260.4915 c
  ibiblio.org n stoof   919.962.8071 f

-
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: [vote] Archiva Logo

[Carlos Sanchez]

[1] Top Left
[2] Lower Right


On 11/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:

Hi,

There seemed to be no major objections to the logos presented, so
I'll turn this into a formal vote.

Please vote [1] for the one you would like and [2] for your second
preference, if you have one, and so on.

Ideally, there will be a clear majority of first preferences. The
lowest scoring choice will be eliminated and their second preference
used, and so on to determine the most popular.

http://people.apache.org/~brett/archiva_logo.gif
Vote will close in 72 hours.

[ ] Top Left
[ ] Top Right
[ ] Lower Left
[ ] Lower Right

I will count the feedback from these people already: Raphael (1 -
Lower Left), Wendell (1 - Lower Left), Milos (1 - Lower Left, 2 -
Lower Right), Henri (1 - Lower Left), Natalie (1 - Top Right), Jesse
(1 - Top Right), Edwin (1 Top Right), Nicolas (1 - Lower Left).

If you want to change your vote, just respond again.

Cheers,
Brett




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

Re: Please vote for Archiva logo

[Kenney Westerhof]

Hi,

LL: 1
LR: 2
UR: 3


Vincent Siveton wrote:

[1] for Top Right and [2] for Lower Left

Cheers,

Vincent


On 08/11/2006, at 12:43 PM, Brett Porter wrote:


Hi,

There seemed to be no major objections to the logos presented, so I'll 
turn

this into a formal vote.

Please vote [1] for the one you would like and [2] for your second
preference, if you have one, and so on.

Ideally, there will be a clear majority of first preferences. The lowest
scoring choice will be eliminated and their second preference used, 
and so

on to determine the most popular.

http://people.apache.org/~brett/archiva_logo.gif
Vote will close in 72 hours.

[ ] Top Left
[ ] Top Right
[ ] Lower Left
[ ] Lower Right

I will count the feedback from these people already: Raphael (1 - Lower
Left), Wendell (1 - Lower Left), Milos (1 - Lower Left, 2 - Lower Right),
Henri (1 - Lower Left), Natalie (1 - Top Right), Jesse (1 - Top Right),
Edwin (1 Top Right), Nicolas (1 - Lower Left).

If you want to change your vote, just respond again.

Cheers,
Brett

Re: moving maven repository to mirrors.ibiblio.org (fwd)

[Don Sizemore]

|Is mirrors.ibiblio.org balancing the load on the mirrors? Will you leave 
|www.ibiblio.org/maven and www.ibiblio.org/maven2 as redirects to the new 
|location? We need to check for maven1 users that still point there, but 
|for maven2 is fine as they already use repo1.maven.org as central

  Hi Carlos,

  I've copied the maven and maven2 repositories into their new locations 
on mirrors.ibiblio.org, and have created rsync modules on that server.  
We'll leave the old content in their old locations for a while.  I think 
we need three things to happen:

 1) The maven folks (Brett?) update their 4-hourly rsync script to update
/export/mirrors/maven and /export/mirrors/maven2 instead of /public/html

 2) do we need to update the .htaccess files, which expect a RewriteBase 
of /maven, which will become /pub/mirrors/maven on mirrors.ibiblio.org.  
Or we could simply throw a symlink on mirrors.ibiblio if you have one 
.htaccess file that you push out to all of your mirrors?

 3) We need to update this page to point to the new location:
http://maven.apache.org/guides/mini/guide-mirror-settings.html
(note that ggi-project.org and ibiblio.net are both on ibiblio.org)

 3.5) Maybe send out a note to some of the Maven lists noting the change 
in repositories?  Or is that overkill

  thank you,919.962.5646 w
  donald sizemore, ii   919.260.4915 c
  ibiblio.org n stoof   919.962.8071 f

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

Re: [vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Daniel Kulp]

Jason,

The files still don't have the proper Apache header on them.  You added 
the old style (with the copyright date) instead of the new style 
documented at:
http://www.apache.org/legal/src-headers.html
Those need to change.

Also, the pom.xml files need to have the header as well.   Note: there is 
a bug in maven/jdom that may discard the header at deploy time.   Thus, 
it may need to go INSIDE the  tag.

The other files in "src" also need it (fml/faq.fml for example, possibly 
the properties files as well).

Dan


On Wednesday November 29 2006 10:38 am, Jason van Zyl wrote:
> Hi,
>
> This is a group release to attempt to deal with the licensing
> resources that need to be packaged up in all the archives we
> distribute. This is, in particular, and attempt to deal with the JARs
> we release. Namely the binary, source, and javadoc JARs we create
> with the JAR, Source, and JavaDoc plugins respectively.
>
> I have created the Remote Resources Plugin which is documented here:
>
> http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/
>
> And I have created a diagram of the process that is currently
> happening as a result of the changes I have made to the Source, and
> JavaDoc plugins:
>
> http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png
>
> Essentially the remote resources plugins creates a directory of
> resources and modifies the POM at runtime so it carries with it the
> information about this directory. The other archiving plugins then
> look for this resource and insert it into the archives they create if
> found. Ideally the Resource element should have a unique id but the
> directory name will do for now.
>
> You can see here that I've created a profile which will enable the
> remote resources plugins and pull down the bundle that contains the
> standard license and notice files:
>
> http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml
>
> And I have deployed all the plugins above with this tool chain so you
> can see them here:
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
> plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
> plugins/maven-source-plugin/2.0.2-SNAPSHOT/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/
> plugins/maven-javadoc-plugin/2.2-SNAPSHOT/
>
> If I can release these plugins then I think we can solve most of the
> licensing/resource doldrums.
>
> Jason.
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

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

[vote] Release Remote Resources Plugin / JavaDoc Plugin / Source Plugin

[Jason van Zyl]

Hi,

This is a group release to attempt to deal with the licensing  
resources that need to be packaged up in all the archives we  
distribute. This is, in particular, and attempt to deal with the JARs  
we release. Namely the binary, source, and javadoc JARs we create  
with the JAR, Source, and JavaDoc plugins respectively.


I have created the Remote Resources Plugin which is documented here:

http://people.apache.org/~jvanzyl/maven-remote-resources-plugin/

And I have created a diagram of the process that is currently  
happening as a result of the changes I have made to the Source, and  
JavaDoc plugins:


http://idisk.maven.org/jvanzyl/Public/RemoteResourcesHandling.png

Essentially the remote resources plugins creates a directory of  
resources and modifies the POM at runtime so it carries with it the  
information about this directory. The other archiving plugins then  
look for this resource and insert it into the archives they create if  
found. Ideally the Resource element should have a unique id but the  
directory name will do for now.


You can see here that I've created a profile which will enable the  
remote resources plugins and pull down the bundle that contains the  
standard license and notice files:


http://svn.apache.org/repos/asf/maven/plugins/trunk/pom.xml

And I have deployed all the plugins above with this tool chain so you  
can see them here:


http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/ 
plugins/maven-remote-resources-plugin/1.0-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/ 
plugins/maven-source-plugin/2.0.2-SNAPSHOT/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/ 
plugins/maven-javadoc-plugin/2.2-SNAPSHOT/


If I can release these plugins then I think we can solve most of the  
licensing/resource doldrums.


Jason.





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

Re: Common API for issue tracking systems

[Jason van Zyl]

Nice!

On 29 Nov 06, at 9:16 AM 29 Nov 06, Mark Hobson wrote:


On 07/07/06, Mik Kersten <[EMAIL PROTECTED]> wrote:
There should be no problem.  Just file a Mylar bug report with the  
structure
you want and we can iterate from there.  If the easiest way to do  
that is
for us to build those JARs via Maven instead of plain Ant I'm  
happy to do

that too.


Finally got around to raising a bug against Mylar for a Maven build:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=166203

Mark

-
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: Common API for issue tracking systems

[Mark Hobson]

On 07/07/06, Mik Kersten <[EMAIL PROTECTED]> wrote:

There should be no problem.  Just file a Mylar bug report with the structure
you want and we can iterate from there.  If the easiest way to do that is
for us to build those JARs via Maven instead of plain Ant I'm happy to do
that too.


Finally got around to raising a bug against Mylar for a Maven build:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=166203

Mark

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

Re: cyclic dependency in plugins

[Jason van Zyl]

On 29 Nov 06, at 1:35 AM 29 Nov 06, Brett Porter wrote:

You're oversimplifying it. There is no cycle when you run mvn  
install, Maven is misdetecting it.




I cannot even run "mvn clean" in the plugins directory so I'm not  
sure what you're talking about. Try it.


When you generate a site, if you are to do "install site" on both  
without having a working version of either first, then javadoc ->  
checkstyle ->javadoc is never going to be a cycle you can fix.  
You'd need to install both first, then build the site for both to  
make it work.


The reporting dependencies need to only be assessed when you are  
generating the site, not building the plugin. Then, it isn't a  
problem because you can mvn install without any cycle, and mvn site  
has no cycle because the things are already built so the order  
isn't important.


What's more, versions need to be honoured. We should be able to use  
the last javadoc release (and so no dependency in the reactor) for  
the reporting, while building trunk.


Two relatively simple things to fix. The only workaround is to  
remove the reporting plugins from the pom altogether (copying it to  
every plugin will only work if you leave some of them out, eg no  
javadoc on checkstyle).


- Brett

On 29/11/2006, at 4:32 PM, Jason van Zyl wrote:


On 28 Nov 06, at 5:25 PM 28 Nov 06, Brett Porter wrote:


It's filed in JIRA. I think we need to fix Maven.



To allow cycles? I mean the second that cycle was introduced it  
made working with the plugins pretty crappy. How about fixing the  
cycle?


The only way to fix this is to disable the reporting, or copy it  
into every plugin - not really desirable either.


Or fix the cycle??




-
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: How to handle different tool versions in Maven plugins?

[Vincent Massol]

Hi Raphael,

> -Original Message-
> From: leahpar [mailto:[EMAIL PROTECTED]
> Sent: mercredi 29 novembre 2006 14:14
> To: dev@maven.apache.org
> Subject: Re: How to handle different tool versions in Maven plugins?
> 
> 
> hello,
> 
> option 1 will be a good solution with the drawback that some people
> will
> fall into trouble because they are "not allowed" to change anything and
> cannot upgrade (belong to theses...)

I think option 1 with what Carlos suggested would be good, i.e.:

* we create a 2.x branch and all 2.x versions of the clover plugin will be
using Clover 1.x
* on trunk we have the 3.x versions of the plugin which use Clover 2.x

This means we can still deliver 2.x versions even after work on 3.x has
started.
 
> option 3 is the best world to me
> I think that a naming convention to express the version of the
> underlying
> artifacts could be usefull.

Problem of option 3 is that it's costly in term of time and effort and it
also needs another module to hold common things. Not very practical.

> The current issue will be the same for other artifact so it will be
> great to
> have a official way of express it.
> For example in a well known distribution, the package ant has a version
> 1.6.5-6
> It means that this is the revision 6 of the package for the same tools
> ant
> which has the version 1.6.5
> It's the same thing with more complex version number : 0.11.1-1.2
> by this way, it's easier to be up to date on the plugin without
> changing the
> underlying tool.

You're probably right but this is going to be hard to change across the
board. So in a first step I think good documentation would help. For example
on the clover plugin web site, I would write explicitely that 2.x versions
are using Clover 1.x and 3.x are using Clover 2.x

Is that ok with you?

Thanks
-Vincent








___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

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

Re: How to handle different tool versions in Maven plugins?

[leahpar]

hello,

option 1 will be a good solution with the drawback that some people will
fall into trouble because they are "not allowed" to change anything and
cannot upgrade (belong to theses...)

option 3 is the best world to me
I think that a naming convention to express the version of the underlying
artifacts could be usefull.
The current issue will be the same for other artifact so it will be great to
have a official way of express it.
For example in a well known distribution, the package ant has a version
1.6.5-6 
It means that this is the revision 6 of the package for the same tools ant
which has the version 1.6.5
It's the same thing with more complex version number : 0.11.1-1.2 
by this way, it's easier to be up to date on the plugin without changing the
underlying tool.

++

-- 
View this message in context: 
http://www.nabble.com/How-to-handle-different-tool-versions-in-Maven-plugins--tf2720891s177.html#a7599029
Sent from the Maven Developers mailing list archive at Nabble.com.


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

Re: svn commit: r480431 - in /maven/plugins/trunk/maven-javadoc-plugin: pom.xml src/main/java/org/apache/maven/plugin/javadoc/JavadocJar.java

[Jason van Zyl]

On 29 Nov 06, at 1:36 AM 29 Nov 06, Brett Porter wrote:


Is this documented anywhere? I don't quite understand what it means.



Just like the remote resources plugin I'll finish the doco and run it  
through docck.



On 29/11/2006, at 5:29 PM, [EMAIL PROTECTED] wrote:


Author: jvanzyl
Date: Tue Nov 28 22:29:37 2006
New Revision: 480431

URL: http://svn.apache.org/viewvc?view=rev&rev=480431
Log:
o archiver will now pick up dot files to package any resources  
that have been created by other processes like

  license file generation

Modified:
maven/plugins/trunk/maven-javadoc-plugin/pom.xml
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/ 
apache/maven/plugin/javadoc/JavadocJar.java


Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven- 
javadoc-plugin/pom.xml?view=diff&rev=480431&r1=480430&r2=480431
= 
=

--- maven/plugins/trunk/maven-javadoc-plugin/pom.xml (original)
+++ maven/plugins/trunk/maven-javadoc-plugin/pom.xml Tue Nov 28  
22:29:37 2006

@@ -110,7 +110,7 @@
 
   org.codehaus.plexus
   plexus-archiver
-  1.0-alpha-7
+  1.0-alpha-8-SNAPSHOT
 
 
   org.apache.maven.shared

Modified: maven/plugins/trunk/maven-javadoc-plugin/src/main/java/ 
org/apache/maven/plugin/javadoc/JavadocJar.java
URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven- 
javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/ 
JavadocJar.java?view=diff&rev=480431&r1=480430&r2=480431
= 
=
--- maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/ 
apache/maven/plugin/javadoc/JavadocJar.java (original)
+++ maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/ 
apache/maven/plugin/javadoc/JavadocJar.java Tue Nov 28 22:29:37 2006

@@ -154,6 +154,8 @@

 JarArchiver archiver = new JarArchiver();

+archiver.setDotFileDirectory( new File( project.getBuild 
().getDirectory() ) );

+
 archiver.addDirectory( javadocFiles );

 archiver.setDestFile( javadocJar );



-
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: Maven's classpaths (Was: [discuss] Java 5)

[Emmanuel Hugonnet]

[EMAIL PROTECTED] a écrit :
Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 
15:54:34:


  
I have to edit the pom.xml of 
maven-plugin-tools-java to set the version of qdox to 1.6.1 and then 

all 
  

is fine.


Hi,
This is a temporary solution I use with a proximity proxy and an 
overriding pom.xml but my question is more theorical than practical ;-)

Why can't I override this dependency?



In the pom, you can tell maven how to compile and test *your* code. From 
maven's point of view, the maven-plugin-tools-java is "external" and 
outside the scope of the dependencies in your pom.xml.


Imagine: A plugin depends on some class in qdox 1.5 which is deprecated 
and was removed in qdox 1.6. Now, your project says "I depend on qdox 
1.6". If maven took this into account when loading plugins, the plugin 
wouldn't work and there was no way to make it work without breaking the 
build of your project. A deadlock.


Therefore, maven carefully separates the classpaths from every plugin from 
your project. You can have plugin A which needs qdox 1.5 and plugin B 
which needs qdox 2.0 in the *same* build and include qdox 1.6 in your 
project and it will work.


A solution might be to extend maven's xml merge mechanism. If you could 
add "patches" to pom.xml and settings.xml//profile, then it would be 
possible to override the values in other POM's (for example, to patch the 
POM of maven-plugin-tools-java to depend on a different version of qdox).


Here, I must ask how economical that would be. As it is, the solution is 
simple (at least when you're used at how simple it is to setup and compile 
maven projects) and the question is how useful such a patch mechanism will 
be (ie. how often can you fix your problems with it?).


Regards,

  

Hi,
Thank you, this was the answer I was looking for :o) I thought I was 
missing something and you pointed right to it. I understand your point 
of view and agree with it. I will stick to my solution with my modified 
version of maven-plugin-tools-java waiting for the futur release.

Regards,
Emmanuel

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

Re: Maven's classpaths (Was: [discuss] Java 5)

[Aaron . Digulla]

Emmanuel Hugonnet <[EMAIL PROTECTED]> schrieb am 28.11.2006 
15:54:34:

> >> I have to edit the pom.xml of 
> >> maven-plugin-tools-java to set the version of qdox to 1.6.1 and then 
all 
> >> is fine.
> Hi,
> This is a temporary solution I use with a proximity proxy and an 
> overriding pom.xml but my question is more theorical than practical ;-)
> Why can't I override this dependency?

In the pom, you can tell maven how to compile and test *your* code. From 
maven's point of view, the maven-plugin-tools-java is "external" and 
outside the scope of the dependencies in your pom.xml.

Imagine: A plugin depends on some class in qdox 1.5 which is deprecated 
and was removed in qdox 1.6. Now, your project says "I depend on qdox 
1.6". If maven took this into account when loading plugins, the plugin 
wouldn't work and there was no way to make it work without breaking the 
build of your project. A deadlock.

Therefore, maven carefully separates the classpaths from every plugin from 
your project. You can have plugin A which needs qdox 1.5 and plugin B 
which needs qdox 2.0 in the *same* build and include qdox 1.6 in your 
project and it will work.

A solution might be to extend maven's xml merge mechanism. If you could 
add "patches" to pom.xml and settings.xml//profile, then it would be 
possible to override the values in other POM's (for example, to patch the 
POM of maven-plugin-tools-java to depend on a different version of qdox).

Here, I must ask how economical that would be. As it is, the solution is 
simple (at least when you're used at how simple it is to setup and compile 
maven projects) and the question is how useful such a patch mechanism will 
be (ie. how often can you fix your problems with it?).

Regards,

-- 
Aaron Digulla


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

Fwd: Undocumented property expansion?

[Stefan Hübner]

Hi guys,

I'm rather curious about that construction mentioned below, but
couldn't get any responses on the user-list. would you mind, providing
me a pointer to some information or if it's supposed to work at all?

sorry for hesitating,
-Stefan

-- Forwarded message --
From: Stefan Hübner <[EMAIL PROTECTED]>
Date: 27.11.2006 17:44
Subject: Undocumented property expansion?
To: maven-users 


Hi all,

the other day I found this statement inside commons-logging-1.1.pom
():

"http://jakarta.apache.org/commons/${pom.artifactId.substring(8)}/"

I tried the same "substring"-thing in my poms, but Maven didn't expand
the URL like I would have expected. Is a statement like that actually
supposed to work? If so, is there a common pattern to use similar
features (e.g. ${groupId.replaceAll(".", "/")} )?

Any hints? Thanks in advance!
-Stefan

Re: [Maven 1.x] How to modify the version of the dependencies of a project ?

[Stephane Nicoll]

Sounds weird. Why do you want to do that?

Anyway, once maven has loaded the pom, the dependencies are resolved. The
only thing I see is to put a variable in your version(s) and switch the
parameter on command line.

But I won't certainly find this a best practice.

Cheers,
Stéphane

On 11/29/06, Blaise Gosselin <[EMAIL PROTECTED]> wrote:


Hello,

I'd like to loop over all the dependencies and change their version number
in a given version number.
I know how to loop over the dependencies of a project.
But I don't know if it is actually possible to modify the version of a
dependency in a project.xml file ?

Any help is welcome... ;-)
Thanks in advance.
_ _ _ _
bgOnline

RE: How to handle different tool versions in Maven plugins?

[Vincent Massol]

> -Original Message-
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: mardi 28 novembre 2006 23:36
> To: Maven Developers List
> Subject: Re: How to handle different tool versions in Maven plugins?
> 
> I'd actually go with (1), creating a branch for bugfixes on the old
> one. (3) sounds good if there is expected to be a lot of changes
> still needed for clover1.

I also prefer (1). I like Carlos suggestions of using a 3.x versioning
scheme for Clover 2.x.

Thanks
-Vincent

> On 29/11/2006, at 7:49 AM, Vincent Massol wrote:
> 
> > Hi,
> >
> > As you may have seen Clover2 is going to be out soon and I was
> > thinking
> > about how we would go about adding support for it. We already have
> > a Clover1
> > plugin. Although this is about Clover it's really a general
> > strategy that we
> > may want to have for all other tools.
> >
> > I can see the following options:
> >
> > * option 1: make the next version of the clover plugin use clover2.
> In
> > essence this means we won't support anymore clover1.
> > * option 2: add a flag to choose the clover version to use in the
> > plugin.
> > Possible but too messy I think.
> > * option 3: create a maven-clover2-plugin plugin for clover2.
> > Issue: need to
> > sort out duplicated code by creating a third module for common code.
> >
> > WDYT? Are there other options?
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> __
> > _
> > Découvrez une nouvelle façon d'obtenir des réponses à toutes vos
> > questions !
> > Profitez des connaissances, des opinions et des expériences des
> > internautes sur Yahoo! Questions/Réponses
> > http://fr.answers.yahoo.com
> >
> > -
> > 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]






___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com

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

RE: How to handle different tool versions in Maven plugins?

[Vincent Massol]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Carlos Sanchez
> Sent: mardi 28 novembre 2006 23:20
> To: Maven Developers List
> Subject: Re: How to handle different tool versions in Maven plugins?
> 
> waht about having 2.x branch for clover 1 and make 3.x for clover 2 ?

Yes I thought about that and this would definitely be my preference.

I wasn't sure if we wanted to align plugin versions with Maven core versions
and keep the 3.x versions for Maven 3.x ;-)

If it's ok to use 3.x versions in a plugin for Maven 2.x then this is
probably the best solution.

Thanks
-Vincent

> On 11/28/06, Vincent Massol <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > As you may have seen Clover2 is going to be out soon and I was
> thinking
> > about how we would go about adding support for it. We already have a
> Clover1
> > plugin. Although this is about Clover it's really a general strategy
> that we
> > may want to have for all other tools.
> >
> > I can see the following options:
> >
> > * option 1: make the next version of the clover plugin use clover2.
> In
> > essence this means we won't support anymore clover1.
> > * option 2: add a flag to choose the clover version to use in the
> plugin.
> > Possible but too messy I think.
> > * option 3: create a maven-clover2-plugin plugin for clover2. Issue:
> need to
> > sort out duplicated code by creating a third module for common code.
> >
> > WDYT? Are there other options?
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> ___
> 
> > Découvrez une nouvelle façon d'obtenir des réponses à toutes vos
> questions !
> > Profitez des connaissances, des opinions et des expériences des
> internautes sur Yahoo! Questions/Réponses
> > http://fr.answers.yahoo.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]






___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur 
Yahoo! Questions/Réponses
http://fr.answers.yahoo.com

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