Re: axis2-wsdl2code:wsdl2code

[Wayne Fay]

Post your questions about the Axis2 plugin on the Maven Users list.
The author of that plugin reads the User list, and I'm not sure if he
reads this Dev list.

Someone else just recently posted some questions about that plugin,
and the author responded very quickly.

Wayne

On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Can someone help me to implement axis2-wsdl2code:wsdl2code plug - in.

I am sure what are the dependency I need to put for using this plug-in

Thanks
Jaish

-
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: Design & Best Practices

[jira]

Issue Subscription
Filter: Design & Best Practices (37 issues)
Subscriber: mavendevlist


Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
http://jira.codehaus.org/browse/MNG-612
MNG-2125[doc] when and how to define plugins in a pom
http://jira.codehaus.org/browse/MNG-2125
MNG-1936pattern: for mojo parameters which have default values in the POM 
we need standard usage
http://jira.codehaus.org/browse/MNG-1936
MNG-1950Ability to introduce new lifecycles phases
http://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
http://jira.codehaus.org/browse/MNG-2381
MNG-1634move maven-core-it to integration-tests
http://jira.codehaus.org/browse/MNG-1634
MNG-1381best practices: testing strategies
http://jira.codehaus.org/browse/MNG-1381
MNG-1563how to write integration tests
http://jira.codehaus.org/browse/MNG-1563
MNG-474 performance improvement for forked lifecycles
http://jira.codehaus.org/browse/MNG-474
MNG-1305Document Maven's own development process
http://jira.codehaus.org/browse/MNG-1305
MNG-1931add a reportingManagement section
http://jira.codehaus.org/browse/MNG-1931
MNG-2477Implement repository security improvements for verification of 
downloaded artifacts
http://jira.codehaus.org/browse/MNG-2477
MNG-2642maven-archetype-webapp does not produce Standard Directory Layout
http://jira.codehaus.org/browse/MNG-2642
MNG-1867deprecate system scope, analyse other use cases
http://jira.codehaus.org/browse/MNG-1867
MNG-1440Developer Object Model (DOM)
http://jira.codehaus.org/browse/MNG-1440
MNG-1439Organization Object Model (OOM) 
http://jira.codehaus.org/browse/MNG-1439
MNG-1569Make build process info read-only to mojos, and provide mechanism 
for explicit out-params for mojos to declare
http://jira.codehaus.org/browse/MNG-1569
MNG-905 review clean repo install of m2 for download trimming
http://jira.codehaus.org/browse/MNG-905
MNG-1463best practices: plugin inheritance for a multi project build
http://jira.codehaus.org/browse/MNG-1463
MNG-939 specify maven settings from command line
http://jira.codehaus.org/browse/MNG-939
MNG-41  best practices: site management
http://jira.codehaus.org/browse/MNG-41
MNG-1885Uniquely identify modules by module name and version number
http://jira.codehaus.org/browse/MNG-1885
MNG-140 refactor maven-artifact
http://jira.codehaus.org/browse/MNG-140
MNG-1452best practices: deployment of aggregate JARs produced by the 
assembly plug-in
http://jira.codehaus.org/browse/MNG-1452
MNG-1423best practices: setting up multi-module build
http://jira.codehaus.org/browse/MNG-1423
MNG-139 server definitions should be reusable
http://jira.codehaus.org/browse/MNG-139
MNG-868 Use uniform format for  and other tags
http://jira.codehaus.org/browse/MNG-868
MNG-125 guarded mojo execution
http://jira.codehaus.org/browse/MNG-125
MNG-367 best practices: multi-user installation
http://jira.codehaus.org/browse/MNG-367
MNG-647 Allow Maven 2 to be monitored using JMX.
http://jira.codehaus.org/browse/MNG-647
MNG-1441Starting thinking about a proper distributed repository mechanism a 
la CPAN
http://jira.codehaus.org/browse/MNG-1441
MNG-416 best practices:  multiple profile deployments
http://jira.codehaus.org/browse/MNG-416
MNG-1437How to make additions to the POM and have it be backward/forward 
compatible
http://jira.codehaus.org/browse/MNG-1437
MNG-1425best practices: the location of configuration files vs resources
http://jira.codehaus.org/browse/MNG-1425
MNG-657 possible chicken and egg problem with extensions
http://jira.codehaus.org/browse/MNG-657
MNG-1468best practices: version management in multi project builds
http://jira.codehaus.org/browse/MNG-1468


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

axis2-wsdl2code:wsdl2code

[Jaish.Singh]

Can someone help me to implement axis2-wsdl2code:wsdl2code plug - in.

I am sure what are the dependency I need to put for using this plug-in

Thanks
Jaish

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

Re: Changes plugin contribution

[Emmanuel Venisse]

Emmanuel Hugonnet a écrit :

zze-HUGONNET E ext RD-BIZZ a écrit :

Emmanuel Hugonnet a écrit :

Stephane Nicoll a écrit :

Hi,

Where is the source code of your plugin? If it's valuable we can
certainly have a look :)

Thanks,
Stéphane

On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:

Hi,
I have developped a Maven2 plugin that build a report equivalent to 
the
changes report but which uses svn comment parsing instead of 
changes.xml.
The parsing rules are configurable and can be overriden (I am 
providing

2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to 
create

them.
I would like to contribute it to the maven-changes-plugin since it 
loks
to be a feature improvement of it. The only problem with this 
plugin is
that is doesn't use plexus-utils for the cli but my 'own' 
implementation

using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel



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



Sorry if I make a double post.
Well it is currently on my workstation. I can send it to you by mail 
or maybe I could create a JIRA for the changes-plugin and put it there.

What is the best solution ?
Emmanuel

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



Ok
I have attached the code with the JIRA *MCHANGES-78 
.
*Give it a try ;o) You should have some comment on your svn with 
@fix:bug_ref; Comment or @update:;Comment etc.
Feel free to ask any question if it is not clear as I am not an 
english spoken person ;o)

Emmanuel

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



I have rewritten it to be compatible with JDK 1.4 .
As for Emmanuel's remarks I agree that it should be better but Maven-SCM 
is not easy to use since I have to create my own svn provider (extending 
the current one) just to add the xml option.  Also it seems to execute 
the list and log commands recursively (maybe I made some mistakes while 
trying to use it) and I just gave up :o(
If you think that this plugin is useful and someone could spare some 
time or some example on own to start with plexus cli and Maven-SCM 
considering these issues I would gratefully comply to Emmanuel's remarks 
and clean my code.


I don't know why you need the list command (haven't look at your code yet) but 
for the log command, you can look at the changelog plugin, it's its job.

Emmanuel


Thanks,
Emmanuel

-
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: Plugin version removal proposal

[Raphaël Piéroni]

2007/5/3, Brett Porter <[EMAIL PROTECTED]>:

Any other thoughts on this proposal, given that we replace the
packaging plugin concept with a descriptor instead?


Do that mean anything for the archetypes? i use maven-plugin
packaging to have the group metadata for the archetypes.

Raphaël




- Brett

On 21/04/2007, at 10:57 PM, Brett Porter wrote:

> Hi,
>
> I thought to gather up that massive thread I've just read, I could
> throw out a quick proposal that might summarise it and serve as a
> discussion point.
>
> Things we know:
> - the current situation is problematic
> - we can't require versions for everything (particularly, the
> implied plugins from the lifecycle - too much burden on the users)
> - we can't put the versions in the maven installation (the POM must
> be the definitive reference for how to build the software, changing
> maven installations should have no effect - except for fixing bugs
> and adding features some builds might require)
>
> Side note:
> - we *could* use the super POM. I don't think it's ideal in this
> case (since you'd have to increment the model version too often to
> keep up with the plugin releases), but it should be noted that the
> super POM *is not* tied to the Maven version. If it changes, it
> should be tied to the modelVersion.
>
> The discussion also touched on the following, which I think are
> separate issues:
> - locking down versions at release time where they were not
> specified (a more general problem, as it includes not only RELEASE/
> LATEST, but ranges too).
> - separation of "declaration" from "instantiation" for a POM.
>
> So, here's what I propose:
> - require the version in plugin definitions in the POM from
> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the
> RELEASE as the version).
> - externalise all packagings/lifecycle definitions (with the
> exception of 'pom', perhaps)
> - make the user declare the plugin that contains the packaging they
> want, including it's version (a plugin may contain more than one
> packaging)
> - make the packaging plugin declare the versions of the other
> lifecycle plugins it uses (in the lifecycle itself, not the plugins
> pom)
> - same for any overlaid lifecycles in plugins
> - declared plugins and pluginManagement in the POM always wins over
> the lifecycle.
> - running from the CLI behaves as it does now
>
> Now, while this could mean the jar packaging is in maven-jar-
> plugin, etc. I would suggest that's too many plugins to change when
> the compile plugin changes. So instead we could have the maven-java-
> packages-plugin, v1.0 that has jar, war, ear, ejb, compile,
> surefire, etc. all pinned to a known, tested set. If a user needs
> one of them newer: plugin management.
>
> This does mean that the java packaging plugin gets released more
> often - perhaps even a function of all the other releases. It may
> be a good idea for us to be able to make that plugin's build
> somehow a part of the release of the other plugins, perhaps by
> making it driven by repository metadata (ie, it might not be a real
> plugin, but a virtual one, but still with a deterministic version
> to version mapping). We could start off without this and just
> roadmap the plugin like the others, however.
>
> We should note that this does not tightly couple plugins in the
> same way it has before which was problematic in m1. We are still
> "programming to interfaces" - but the metadata wires up the right
> versions of things. There is nothing in the plugin's pom tying it
> to another plugin.
>
> This solution is:
> - deterministic
> - easy to understand
> - still as flexible as now for the user
> - only a minimum imposition (5-9 lines) on a user
> - only a minimum imposition on the developer/release process (the
> java packaging plugin)
>
> Thoughts?
>
> Cheers,
> 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]

Re: Central Repository for Maven 2.0.6

[Jorg Heymans]

Thierry Barnier wrote:

Hi Jaish,

I would recommend you the following "maven proxies"
->AbstractHorizon Proximity http://proximity.abstracthorizon.org/
->Apache Archiva http://maven.apache.org/archiva/
->Mergere Maestro http://www.mergere.com/
->Maven proxy http://maven-proxy.codehaus.org/


You left out the one i consider to be the best for the moment: 
Artifactory (jfrog.org)



Jorg


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

Re: Changes plugin contribution

[Emmanuel Hugonnet]

zze-HUGONNET E ext RD-BIZZ a écrit :

Emmanuel Hugonnet a écrit :

Stephane Nicoll a écrit :

Hi,

Where is the source code of your plugin? If it's valuable we can
certainly have a look :)

Thanks,
Stéphane

On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:

Hi,
I have developped a Maven2 plugin that build a report equivalent to 
the
changes report but which uses svn comment parsing instead of 
changes.xml.
The parsing rules are configurable and can be overriden (I am 
providing

2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to 
create

them.
I would like to contribute it to the maven-changes-plugin since it 
loks
to be a feature improvement of it. The only problem with this 
plugin is
that is doesn't use plexus-utils for the cli but my 'own' 
implementation

using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel



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



Sorry if I make a double post.
Well it is currently on my workstation. I can send it to you by mail 
or maybe I could create a JIRA for the changes-plugin and put it there.

What is the best solution ?
Emmanuel

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



Ok
I have attached the code with the JIRA *MCHANGES-78 
.
*Give it a try ;o) You should have some comment on your svn with 
@fix:bug_ref; Comment or @update:;Comment etc.
Feel free to ask any question if it is not clear as I am not an 
english spoken person ;o)

Emmanuel

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



I have rewritten it to be compatible with JDK 1.4 .
As for Emmanuel's remarks I agree that it should be better but Maven-SCM 
is not easy to use since I have to create my own svn provider (extending 
the current one) just to add the xml option.  Also it seems to execute 
the list and log commands recursively (maybe I made some mistakes while 
trying to use it) and I just gave up :o(
If you think that this plugin is useful and someone could spare some 
time or some example on own to start with plexus cli and Maven-SCM 
considering these issues I would gratefully comply to Emmanuel's remarks 
and clean my code.

Thanks,
Emmanuel

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

Re: question about POMs in (new) trunk

[Joakim Erdfelt]

That's expected.

On a fresh checkout/update, the modules do not exist in the local (or 
remote) repositories yet.


When you run the eclipse:eclipse goal, it tries to resolve the 
dependencies, it can't as there is no information present in the 
repository system for those modules.


Compile it first,  then run eclipse:eclipse, then import it into eclipse.

- Joakim


nicolas de loof wrote:

You're right, I missed it.

This has a strange side effect : when I run mvn eclipse:eclipse from a 
fresh

checkout, all inter-modules dependencies are unresolved :

[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT 



 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file
-DgroupId=org.apache.maven.archiva-DartifactId=archiva-database-consumers
\
 -Dversion=1.0-alpha-1-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1) 
org.apache.maven.archiva:archiva-webapp:war:1.0-alpha-1-SNAPSHOT

   2)
org.apache.maven.archiva:archiva-scheduled:jar:1.0-alpha-1-SNAPSHOT
   3)
org.apache.maven.archiva:archiva-database-consumers:jar:1.0-alpha-1-SNAPSHOT 


...


I can't import all modules in Eclipse before mvn install is successfull.
This may create issues if the code in SVN has compilation failures due to
some unfortunate commit.


2007/5/3, Andrew Williams <[EMAIL PROTECTED]>:


I have not looked, but am guessing there is a dependencyManagement
section in the parent pom.

Andy

On 3 May 2007, at 11:45, nicolas de loof wrote:

> The POMs in the new trunk don't set versions for dependencies on other
> arhiva modules. Maven has no issue with that when running mvn install.
>
> I tried to do the same on my project and got error :
> Validation Messages:
>
>[0]  'dependencies.dependency.version' is missing for
> com.capgemini.quickstart:quickstart-model
>
> Reason: Failed to validate POM
>
>
> I don't see any special version setting in archiva. Did I miss
> something ?
>
> Nico.

Re: Plugin version removal proposal

[Jason van Zyl]

Yup, we have two long slots at the TC offices at j1. 14 hours in  
total and I would like to talk about plugins, and artifact resolution.


Jason.

On 3 May 07, at 6:42 AM 3 May 07, Brett Porter wrote:

Any other thoughts on this proposal, given that we replace the  
packaging plugin concept with a descriptor instead?


- Brett

On 21/04/2007, at 10:57 PM, Brett Porter wrote:


Hi,

I thought to gather up that massive thread I've just read, I could  
throw out a quick proposal that might summarise it and serve as a  
discussion point.


Things we know:
- the current situation is problematic
- we can't require versions for everything (particularly, the  
implied plugins from the lifecycle - too much burden on the users)
- we can't put the versions in the maven installation (the POM  
must be the definitive reference for how to build the software,  
changing maven installations should have no effect - except for  
fixing bugs and adding features some builds might require)


Side note:
- we *could* use the super POM. I don't think it's ideal in this  
case (since you'd have to increment the model version too often to  
keep up with the plugin releases), but it should be noted that the  
super POM *is not* tied to the Maven version. If it changes, it  
should be tied to the modelVersion.


The discussion also touched on the following, which I think are  
separate issues:
- locking down versions at release time where they were not  
specified (a more general problem, as it includes not only RELEASE/ 
LATEST, but ranges too).

- separation of "declaration" from "instantiation" for a POM.

So, here's what I propose:
- require the version in plugin definitions in the POM from  
modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow  
the RELEASE as the version).
- externalise all packagings/lifecycle definitions (with the  
exception of 'pom', perhaps)
- make the user declare the plugin that contains the packaging  
they want, including it's version (a plugin may contain more than  
one packaging)
- make the packaging plugin declare the versions of the other  
lifecycle plugins it uses (in the lifecycle itself, not the  
plugins pom)

- same for any overlaid lifecycles in plugins
- declared plugins and pluginManagement in the POM always wins  
over the lifecycle.

- running from the CLI behaves as it does now

Now, while this could mean the jar packaging is in maven-jar- 
plugin, etc. I would suggest that's too many plugins to change  
when the compile plugin changes. So instead we could have the  
maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,  
compile, surefire, etc. all pinned to a known, tested set. If a  
user needs one of them newer: plugin management.


This does mean that the java packaging plugin gets released more  
often - perhaps even a function of all the other releases. It may  
be a good idea for us to be able to make that plugin's build  
somehow a part of the release of the other plugins, perhaps by  
making it driven by repository metadata (ie, it might not be a  
real plugin, but a virtual one, but still with a deterministic  
version to version mapping). We could start off without this and  
just roadmap the plugin like the others, however.


We should note that this does not tightly couple plugins in the  
same way it has before which was problematic in m1. We are still  
"programming to interfaces" - but the metadata wires up the right  
versions of things. There is nothing in the plugin's pom tying it  
to another plugin.


This solution is:
- deterministic
- easy to understand
- still as flexible as now for the user
- only a minimum imposition (5-9 lines) on a user
- only a minimum imposition on the developer/release process (the  
java packaging plugin)


Thoughts?

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

Re: [vote] release maven-release-plugin 2.0-beta-5

[Vincent Siveton]

+1

Vincent

2007/5/1, Stephane Nicoll <[EMAIL PROTECTED]>:

Hi,

I'd like to release the maven release plugin which includes the maven
release manager and the maven release parent pom.

The staging bits are available here:
http://people.apache.org/~snicoll/maven-staging/repo/


Release Notes - Maven 2.x Release Plugin - Version 2.0-beta-5

** Bug
* [MRELEASE-3] - release:prepare should not require multimodule
artifacts to be in the local repository
* [MRELEASE-6] - Multiproject Release: No check in
* [MRELEASE-16] - release-pom is changed too much
* [MRELEASE-35] - release plugin doesn't tag correctly with
svn+ssh when remote and local username don't match
* [MRELEASE-90] - Exception if version is SNAPSHOT
* [MRELEASE-91] - Updating of dependencyManagement inconsistent
with updating of dependencies with regard to SNAPSHOTs
* [MRELEASE-94] - Modified Parent POM is not commited
* [MRELEASE-107] - scm.url gets translated incorrectly during release
* [MRELEASE-110] - release:prepare generates tags with dots,
causing problems with CVS
* [MRELEASE-114] - ${project.artifactId} was replaced with it's
value during release:perform
* [MRELEASE-115] - Issue URL on pom is incorrect
* [MRELEASE-116] - Wrong SCM info put by the release plugin for modules
* [MRELEASE-122] - Versionless Extension causes
NullPointerException in release:prepare
* [MRELEASE-128] - SCM properties being replaced during release:perform
* [MRELEASE-131] - release:prepare failed in 'cvs ... commit'
phase for multi-module build
* [MRELEASE-137] - proposed SCM release tag or label in multiproject
* [MRELEASE-142] - Batch mode release plugin uses an invalid tag
* [MRELEASE-144] - Release plugin did not ask for a Subversion tag
* [MRELEASE-147] - Version number for a dependency with
${pom.groupId} not updated in multi-module.
* [MRELEASE-151] - All child modules are forced to share the same parent POM
* [MRELEASE-160] - The next snapshot version is not used un submodules
* [MRELEASE-168] - All submodule projects must be from the same
subversion repository
* [MRELEASE-180] - Rewritten  poms loose comments
* [MRELEASE-190] - scmTagPhase scm comment when creating the
branch/tag directory uses the prefix [maven-scm]
* [MRELEASE-191] - Certain tests fail when checked-out in 'projects' subdir
* [MRELEASE-194] - SNAPSHOT as property bypasses dependency snapshot check
* [MRELEASE-197] - Release plugin documentation on
maven.apache.org has broken link to release:rollback
* [MRELEASE-202] - snapshot versions in dependencyManagement are not updated
* [MRELEASE-209] - Snapshot versions are not restored correctly on
next development version
* [MRELEASE-219] - Spurious warnings given when a release contains
subversion externals
* [MRELEASE-221] - XML header missing in modified POM after release:prepare
* [MRELEASE-222] - Wrong default tag name when used in a reactor environment

** Improvement
* [MRELEASE-112] - release plugin should have option to ignore
snapshots of the release plugin
* [MRELEASE-145] - release:prepare requires all modules to be SNAPSHOTS
* [MRELEASE-183] - should report all unresolved dependencies, not
just the first encountered.
* [MRELEASE-208] - Support for ClearCase, and other SCMs that do
checkout projects to subdirectories of the checkout directory
* [MRELEASE-214] - scm:tag with scmCommentPrefix
* [MRELEASE-220] - Add property to keep released versions for dependencies

** New Feature
* [MRELEASE-130] - Create a model for a release
* [MRELEASE-157] - Share version for multi-module releases
* [MRELEASE-169] - Provide a mechanism to undo the effects of prepare

** Task
* [MRELEASE-141] - Review Plugin Documentation
* [MRELEASE-162] - Move all release core code in maven/shared

Vote open for 72 hours

My +1

Thanks,
Stéphane

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

question about POMs in (new) trunk

[nicolas de loof]

The POMs in the new trunk don't set versions for dependencies on other
arhiva modules. Maven has no issue with that when running mvn install.

I tried to do the same on my project and got error :
Validation Messages:

   [0]  'dependencies.dependency.version' is missing for
com.capgemini.quickstart:quickstart-model

Reason: Failed to validate POM


I don't see any special version setting in archiva. Did I miss something ?

Nico.

Re: Plugin version removal proposal

[Brett Porter]

Any other thoughts on this proposal, given that we replace the  
packaging plugin concept with a descriptor instead?


- Brett

On 21/04/2007, at 10:57 PM, Brett Porter wrote:


Hi,

I thought to gather up that massive thread I've just read, I could  
throw out a quick proposal that might summarise it and serve as a  
discussion point.


Things we know:
- the current situation is problematic
- we can't require versions for everything (particularly, the  
implied plugins from the lifecycle - too much burden on the users)
- we can't put the versions in the maven installation (the POM must  
be the definitive reference for how to build the software, changing  
maven installations should have no effect - except for fixing bugs  
and adding features some builds might require)


Side note:
- we *could* use the super POM. I don't think it's ideal in this  
case (since you'd have to increment the model version too often to  
keep up with the plugin releases), but it should be noted that the  
super POM *is not* tied to the Maven version. If it changes, it  
should be tied to the modelVersion.


The discussion also touched on the following, which I think are  
separate issues:
- locking down versions at release time where they were not  
specified (a more general problem, as it includes not only RELEASE/ 
LATEST, but ranges too).

- separation of "declaration" from "instantiation" for a POM.

So, here's what I propose:
- require the version in plugin definitions in the POM from  
modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the  
RELEASE as the version).
- externalise all packagings/lifecycle definitions (with the  
exception of 'pom', perhaps)
- make the user declare the plugin that contains the packaging they  
want, including it's version (a plugin may contain more than one  
packaging)
- make the packaging plugin declare the versions of the other  
lifecycle plugins it uses (in the lifecycle itself, not the plugins  
pom)

- same for any overlaid lifecycles in plugins
- declared plugins and pluginManagement in the POM always wins over  
the lifecycle.

- running from the CLI behaves as it does now

Now, while this could mean the jar packaging is in maven-jar- 
plugin, etc. I would suggest that's too many plugins to change when  
the compile plugin changes. So instead we could have the maven-java- 
packages-plugin, v1.0 that has jar, war, ear, ejb, compile,  
surefire, etc. all pinned to a known, tested set. If a user needs  
one of them newer: plugin management.


This does mean that the java packaging plugin gets released more  
often - perhaps even a function of all the other releases. It may  
be a good idea for us to be able to make that plugin's build  
somehow a part of the release of the other plugins, perhaps by  
making it driven by repository metadata (ie, it might not be a real  
plugin, but a virtual one, but still with a deterministic version  
to version mapping). We could start off without this and just  
roadmap the plugin like the others, however.


We should note that this does not tightly couple plugins in the  
same way it has before which was problematic in m1. We are still  
"programming to interfaces" - but the metadata wires up the right  
versions of things. There is nothing in the plugin's pom tying it  
to another plugin.


This solution is:
- deterministic
- easy to understand
- still as flexible as now for the user
- only a minimum imposition (5-9 lines) on a user
- only a minimum imposition on the developer/release process (the  
java packaging plugin)


Thoughts?

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

Re: Tool to clean snapshots from the repo

[Mark Hobson]

On 02/05/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 2 May 07, at 2:26 PM 2 May 07, Brian E. Fox wrote:

> Is there any tool or piece of tool in existence that can clean
> snapshots
> from a repo?

Tom's repositorytools in the mojo sandbox.


Which goal specifically?  I can only see:

repositorytools:add-artifact
repositorytools:add-plugin-group
repositorytools:add-repository
repositorytools:copy-artifact
repositorytools:copy-repository
repositorytools:deploy-bundle
repositorytools:deploy-repository
repositorytools:export-csv
repositorytools:validate

Mark

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

Re: Changes plugin contribution

[Stephane Nicoll]

I am not either. I guess you're french and I am belgian (french) so I
think it will be no problem :)

I'll have a look to your patch.

Cheers,
Stéphane

On 5/3/07, Emmanuel Hugonnet <[EMAIL PROTECTED]> wrote:

Emmanuel Hugonnet a écrit :
> Stephane Nicoll a écrit :
>> Hi,
>>
>> Where is the source code of your plugin? If it's valuable we can
>> certainly have a look :)
>>
>> Thanks,
>> Stéphane
>>
>> On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>> I have developped a Maven2 plugin that build a report equivalent to the
>>> changes report but which uses svn comment parsing instead of
>>> changes.xml.
>>> The parsing rules are configurable and can be overriden (I am providing
>>> 2 rules as examples).
>>> Links to the bug trackers are also configurable with currently 2 kinds
>>> of links (JIRA and Sourceforge) but it supports also a pattern to
>>> create
>>> them.
>>> I would like to contribute it to the maven-changes-plugin since it loks
>>> to be a feature improvement of it. The only problem with this plugin is
>>> that is doesn't use plexus-utils for the cli but my 'own'
>>> implementation
>>> using the jdk API for processes.
>>> Is the changes-plugin team  interested in it ?
>>> Should I move it to codehaus and wait for a possible merger after ?
>>> Thanks,
>>> Emmanuel
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> Sorry if I make a double post.
> Well it is currently on my workstation. I can send it to you by mail
> or maybe I could create a JIRA for the changes-plugin and put it there.
> What is the best solution ?
> Emmanuel
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Ok
I have attached the code with the JIRA *MCHANGES-78
.
*Give it a try ;o) You should have some comment on your svn with
@fix:bug_ref; Comment or @update:;Comment etc.
Feel free to ask any question if it is not clear as I am not an english
spoken person ;o)
Emmanuel

-
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: Central Repository for Maven 2.0.6

[Thierry Barnier]

Hi Jaish,

I would recommend you the following "maven proxies"
->AbstractHorizon Proximity http://proximity.abstracthorizon.org/
->Apache Archiva http://maven.apache.org/archiva/
->Mergere Maestro http://www.mergere.com/
->Maven proxy http://maven-proxy.codehaus.org/

Hope this can help

Thierry

2007/5/2, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:


Hi,

I want to create central repository for my project internally and
doesn't want maven to go and download from Maven repo.

Can some one help me to implement this?

Regards
Jaish

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





--
Thierry Barnier - cell: 404-771-3048 - [EMAIL PROTECTED]

Re: Changes plugin contribution

[Emmanuel Hugonnet]

Emmanuel Hugonnet a écrit :

Stephane Nicoll a écrit :

Hi,

Where is the source code of your plugin? If it's valuable we can
certainly have a look :)

Thanks,
Stéphane

On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:

Hi,
I have developped a Maven2 plugin that build a report equivalent to the
changes report but which uses svn comment parsing instead of 
changes.xml.

The parsing rules are configurable and can be overriden (I am providing
2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to 
create

them.
I would like to contribute it to the maven-changes-plugin since it loks
to be a feature improvement of it. The only problem with this plugin is
that is doesn't use plexus-utils for the cli but my 'own' 
implementation

using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel



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



Sorry if I make a double post.
Well it is currently on my workstation. I can send it to you by mail 
or maybe I could create a JIRA for the changes-plugin and put it there.

What is the best solution ?
Emmanuel

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



Ok
I have attached the code with the JIRA *MCHANGES-78 
.
*Give it a try ;o) You should have some comment on your svn with 
@fix:bug_ref; Comment or @update:;Comment etc.
Feel free to ask any question if it is not clear as I am not an english 
spoken person ;o)

Emmanuel

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

Re: maven-install-plugin 2.2 release?

[Jason Dillon]

I don't think it really matters... 2.1.1 or 2.2... I don't care...  
don't think anyone else does either (cept maybe you since you brought  
it up :-P).


--jason


On May 2, 2007, at 11:07 PM, Stephane Nicoll wrote:


Don't label it 2.2 then.

I am fan of the release early, release often paradigm as well but we
need to provide understandable release number scheme.

Brian worked on it meanwhile so let's just release it indeed; 2.1.1
would have been better though.

Stéphane

On 5/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote:

I don't see any reason why you don't release 2.2 asis now, then move
these issues to 2.3.

Waiting for issues to magically fix themselves before pushing out a
release which actually does fix problems now is rather pointless and
a little bit harmful (cause if someone really needs this, and you
folks haven't released it in months and months, then folks are going
to be more likely to hack in into their repositories, or fork it, and
neither of these is really healthy for the mvn community... so just
release it).

--jason


On May 2, 2007, at 3:09 PM, Stephane Nicoll wrote:

> There's around 4 issues to fix before we can release 2.2. Not  
sure it

> will happen short term unless someone handles those issues.
>
> Stéphane
>
> On 5/2/07, Christian Gruber <[EMAIL PROTECTED]>  
wrote:

>> Greetings all,
>>
>>  Any ideas on how close maven-install-plugin 2.2-SNAPSHOT  
is to a
>> release.  I'd like to release my Flex2 plugin in 1.0, but its  
testing

>> relies on the install 2.2 plugin, and it won't let me do a clean
>> release with the maven-release-plugin while I'm depending on 2.2-
>> SNAPSHOT.
>>
>>  I can always release manually or just take out the  
integration

>> tests for the release but that seems like cheating. :)
>>
>> Christian.
>>
>>
>>  
-

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




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

Re: Changes plugin contribution

[Emmanuel Hugonnet]

Stephane Nicoll a écrit :

Hi,

Where is the source code of your plugin? If it's valuable we can
certainly have a look :)

Thanks,
Stéphane

On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:

Hi,
I have developped a Maven2 plugin that build a report equivalent to the
changes report but which uses svn comment parsing instead of 
changes.xml.

The parsing rules are configurable and can be overriden (I am providing
2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to create
them.
I would like to contribute it to the maven-changes-plugin since it loks
to be a feature improvement of it. The only problem with this plugin is
that is doesn't use plexus-utils for the cli but my 'own' implementation
using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel



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



Sorry if I make a double post.
Well it is currently on my workstation. I can send it to you by mail or 
maybe I could create a JIRA for the changes-plugin and put it there.

What is the best solution ?
Emmanuel

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

Re: ApacheCon EU

[Martin van den Bemt]

I'll see if I can come, but I have a meeting during lunch and really need to go 
to Cliffs sessions..

Mvgr,
Martin

Brett Porter wrote:
> I'm thinking between lunch and coffee break tomorrow is a good time.
> 
> On 25/04/2007, at 1:42 AM, Brett Porter wrote:
> 
>> Hi,
>>
>> I saw that Dennis, Jason, Kenney, Eric, Martin, Robert, and Arnaud B
>> will all be at AC EU next week - is anyone else attending ApacheCon?
>>
>> I think it would be good to get some time in front of a white board to
>> go through a couple of the big issues while we have the opportunity
>> for face time and to hack some things together. It sounds like the
>> same opportunity will present itself at JavaOne too. Of course, we can
>> discuss some in real time with people on IRC and bring any output back
>> to the list so everyone gets a chance to participate.
>>
>> What day/time would suit people?
>>
>> Maybe the following are appropriate for AC:
>> - anything more we can do for releases (polish up the staging stuff,
>> incorporate RAT, ...?)
>> - plugin integration testing and unit testing
>> - roadmap discussion / highlighting other issues
>>
>> Any other thoughts? Interest from the folks attending in anything in
>> particular?
>>
>> - 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]

Re: Changes plugin contribution

[Stephane Nicoll]

Hi,

Where is the source code of your plugin? If it's valuable we can
certainly have a look :)

Thanks,
Stéphane

On 5/3/07, ehsavoie <[EMAIL PROTECTED]> wrote:

Hi,
I have developped a Maven2 plugin that build a report equivalent to the
changes report but which uses svn comment parsing instead of changes.xml.
The parsing rules are configurable and can be overriden (I am providing
2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to create
them.
I would like to contribute it to the maven-changes-plugin since it loks
to be a feature improvement of it. The only problem with this plugin is
that is doesn't use plexus-utils for the cli but my 'own' implementation
using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel



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

Changes plugin contribution

[ehsavoie]

Hi,
I have developped a Maven2 plugin that build a report equivalent to the
changes report but which uses svn comment parsing instead of changes.xml.
The parsing rules are configurable and can be overriden (I am providing
2 rules as examples).
Links to the bug trackers are also configurable with currently 2 kinds
of links (JIRA and Sourceforge) but it supports also a pattern to create
them.
I would like to contribute it to the maven-changes-plugin since it loks
to be a feature improvement of it. The only problem with this plugin is
that is doesn't use plexus-utils for the cli but my 'own' implementation
using the jdk API for processes.
Is the changes-plugin team  interested in it ?
Should I move it to codehaus and wait for a possible merger after ?
Thanks,
Emmanuel