date:20081216



On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote:



Also in the course of 6 months of development of the model-builder  
we have not had a single contribution from anyone else. Zero  
interest. So yes, it is easier to release elsewhere and that has  
allowed me to patch, test, release in rapid succession to try and  
get the alpha-1 to the point of release.




I wouldn't say zero interest. I simply have found it impossible to  
keep up with all the svn commits in all the various branches.  
Furthermore, a lot of stuff was being worked on in somewhat private  
branches. Unless they ask for collaboration I'm not going to go review  
stuff in someone's private sandbox until they call out and say it is  
ready for review before merging.


Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM construction specification

On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:

This is for the general population but I'm nudging you Ralph because
I know that you want to make some changes for not requiring the
version in the parent element.

You should have warned me to have a glass of wine before attempting to
read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
for those of use who haven't had a math class in the last 25 years.
The funny thing is, I have a B.S. in Physics. Man it has been a long
time. :-(

Comments:
1.1 Mentions there are 465 model properties. An appendix should list
them. Specifically, I'd like to see provides listed along with the
project's groupId, artifactId and version and requires in the
dependency declaration - or whatever other way that kind of metadata
will be added.
2.1 2.2 Is all this simply stating that the closest definition wins
and when two or more are equally close then the first one wins?
2.4 The only definition of mixin is The only diﬀerence between a
parent pro ject and a mixin is that the mixin is
abstract (not a complete model). That sure leaves a lot to the
imagination. And what exactly makes a model incomplete? Isn't a pom
with just a dependencyManagement complete? I also found myself
wondering that even though it might be possible to support extending
multiple parents, should we? I could see allowing only one parent but
multiple mixins.
3.1 Even though may be obvious, it should explicitly state that
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least be
set from project.parent.groupIdt)?
3.4 The footnote says the artifactId can be inherited from the parent.
That makes no sense to me. Every pom should represent a unique
artifact or at least a unique pom.
3.5 I found the statement This will mark the container as ﬁnal, thus
preventing inheritance: as misleading. In java terms this would mean
a child pom attempting to define the same plugin would fail. The
setting of inherited to false in the sample indicates to me the
opposite, the plugin definition in the parent is invisible to the
child. Here is a question though. If A overrides a plugin defined in
the super pom and has inherited true, then B extends A and overrides
the plugin and sets inherited to false, what will C which extends from
B get? It should see the definition in A. Or does this whole section
mean that the plugin definition in B inherits nothing from A?
3.8 the element will be inherited. Unless the parent definition has
inheritedfalse/inherited ?

I don't see anything in here about being able to locate a parent
without having to know its version. Within the scope of the purpose of
this document it may not be relevant, but at the very least somewhere
in section 3 it should state that if a parent is specified than which
elements are required.

I hope this was the kind of feedback you were looking for.
Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main

2008-12-16 Thread Benjamin Bentmann


Hi Oleg,


Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880

URL: http://svn.apache.org/viewvc?rev=726880view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done, PGP unit 
test works on osx. Need test keyrings for other platforms.

[...]

@@ -30,7 +40,7 @@
 public class Config
 extends AbstractDataType
 {
-  private static final Language LANG = new DefaultLanguage( Config.class );
+  private static final Language _lang = new DefaultLanguage( Config.class );
   
   CollectionRepo _repos;
   
@@ -178,6 +123,22 @@

 String _authid;
 String _proxyauthid;
 
+boolean _readable = true;

+boolean _writeable = false;
+
+ListVerify _writeVerifiers;

+ListVerify _readVerifiers;
+
+public void setReadable( boolean readable )
+{
+  this._readable = readable;
+}
+
+
@@ -207,6 +168,135 @@

 {
   return _dir != null;
 }
+
+public Verify createVerifywrite()

+{
+  if( _writeVerifiers == null )
+_writeVerifiers = new ArrayListVerify(2);


Please adopt our community conventions for Java code style [0, 1] which 
is usually as easy as importing the provided formatter configs into the IDE.


A consistent formatting eases reading/reviewing the code and more 
importantly simplifies contributing/patching.


Thanks


Benjamin


[0] 
http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style

[1] http://maven.apache.org/developers/conventions/code.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main


Hey Ben,

Benjamin Bentmann wrote:

Hi Oleg,


Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880

URL: http://svn.apache.org/viewvc?rev=726880view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done, 
PGP unit test works on osx. Need test keyrings for other platforms.



Modified: 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java 

URL: 
http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java?rev=726880r1=726879r2=726880view=diff 

== 

--- 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java 
(original)
+++ 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java 
Mon Dec 15 16:04:14 2008

@@ -593,35 +595,35 @@
   public static void main( String[] args )
   throws IOException, StreamObserverException
   {


It looks odd for a utility class to have main() method. If it serves a 
production purpose, wouldn't it be better to move the main() out into 
a dedicated class, say in the default package with a descriptive name 
for easy invocation from CLI? If it's only for testing, src/main/java 
is definitively the wrong place.



Maybe ...
Likewise, RepositoryUpdateIntervalPolicy from the mercury-repo-api 
contains a main() method which pretty much looks like test code that 
should be deleted/moved out.

This one - agree, I missed it when cleaning


   
//--- 


+  public static InputStream toStream( String resource )
+  throws MalformedURLException, IOException
+  {
+if( Util.isEmpty( resource ) )
+  return null;
++if( resource.startsWith( file:// )
+|| resource.startsWith( http://; )
+)
+  return new URL(resource).openStream();
+
+return new FileInputStream( new File(resource) );
+  }


RFC 2396 [0], section 3.1, Scheme Component suggests to
treat upper case letters as equivalent to lower case in scheme names 
(e.g., allow HTTP as well as http)


Also, can you elaborate what motivates the selection of only file:// 
and http://; as protocols? For instance, whereever HTTP is used the 
option of HTTPS isn't that far. FTP?


Would it maybe better match your intention to just always call 
URL.openStream() and fallback to the FileInputStream in the case the 
former method threw an exception (unknown protocol)?


I will sure enhance it in the future, for now I only needed a specific 
protocol and ability to blend files and URLs. I don't want to enlarge 
the footprint, so ftp is not gonna make it :)


Thanks,
Oleg


Benjamin



[0] http://www.faqs.org/rfcs/rfc2396.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven ant task

2008-12-16 Thread cause


Hello,

I'm having problem setting ant attributes with a property passed from pom
file.

Here is the pom part where I call ant target:
 
ant antfile=build.xml target=update-dependencies-in-shared-repository
property name=shared-repo
value=${shared.repository}/
 /ant

Here is the ant file:

project name=Update Shared Repository
default=update-dependencies-in-shared-repository
 xmlns:artifact=urn:maven-artifact-ant

path id=maven-ant-tasks.classpath
path=lib/maven-ant-tasks-2.0.9.jar/
typedef resource=org/apache/maven/artifact/ant/antlib.xml
uri=urn:maven-artifact-ant
 classpathref=maven-ant-tasks.classpath/

target name=update-dependencies-in-shared-repository 
echo${shared-repo}/echo
artifact:dependencies filesetId=dependency.fileset
artifact:pom id=maven.project file=pom.xml/
artifact:localRepository path=${shared-repo}/
/artifact:dependencies
/target

/project

I'm interested in using ${shared-repo} parameter, but although echo prints
the correct value of this parameter, it doesn't set localRepository path
(and default is used instead).
Hope my problem is clear and not too stupid :). Any help would be
appreciated. 
Thanks
-- 
View this message in context: 
http://www.nabble.com/maven-ant-task-tp21037680p21037680.html
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main


Ben,

Benjamin Bentmann wrote:

Hi Oleg,


Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880

URL: http://svn.apache.org/viewvc?rev=726880view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done, 
PGP unit test works on osx. Need test keyrings for other platforms.


[...]

@@ -30,7 +40,7 @@
 public class Config
 extends AbstractDataType
 {
-  private static final Language LANG = new DefaultLanguage( 
Config.class );
+  private static final Language _lang = new DefaultLanguage( 
Config.class );

  CollectionRepo _repos;
   @@ -178,6 +123,22 @@
 String _authid;
 String _proxyauthid;
 +boolean _readable = true;
+boolean _writeable = false;
++ListVerify _writeVerifiers;
+ListVerify _readVerifiers;
+
+public void setReadable( boolean readable )
+{
+  this._readable = readable;
+}
+
+@@ -207,6 +168,135 @@
 {
   return _dir != null;
 }
++public Verify createVerifywrite()
+{
+  if( _writeVerifiers == null )
+_writeVerifiers = new ArrayListVerify(2);


Please adopt our community conventions for Java code style [0, 1] 
which is usually as easy as importing the provided formatter configs 
into the IDE.


A consistent formatting eases reading/reviewing the code and more 
importantly simplifies contributing/patching.
Please don't make mass changes without talking. I am still doing a lot 
of modifications and having inconsistent code base - a lot of svn 
conflicts - impedes the process.


Record them as a jira for now.

Thanks,
Oleg


Thanks


Benjamin


[0] 
http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style 


[1] http://maven.apache.org/developers/conventions/code.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main

2008-12-16 Thread Benjamin Bentmann


Hi Oleg,


Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880

URL: http://svn.apache.org/viewvc?rev=726880view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done, PGP unit 
test works on osx. Need test keyrings for other platforms.


Modified: 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java
URL: 
http://svn.apache.org/viewvc/maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java?rev=726880r1=726879r2=726880view=diff
==
--- 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java
 (original)
+++ 
maven/mercury/trunk/mercury-util/src/main/java/org/apache/maven/mercury/util/FileUtil.java
 Mon Dec 15 16:04:14 2008
@@ -593,35 +595,35 @@
   public static void main( String[] args )
   throws IOException, StreamObserverException
   {


It looks odd for a utility class to have main() method. If it serves a 
production purpose, wouldn't it be better to move the main() out into a 
dedicated class, say in the default package with a descriptive name for 
easy invocation from CLI? If it's only for testing, src/main/java is 
definitively the wrong place.


Likewise, RepositoryUpdateIntervalPolicy from the mercury-repo-api 
contains a main() method which pretty much looks like test code that 
should be deleted/moved out.



   
//---
+  public static InputStream toStream( String resource )
+  throws MalformedURLException, IOException
+  {
+if( Util.isEmpty( resource ) )
+  return null;
+
+if( resource.startsWith( file:// )

+|| resource.startsWith( http://; )
+)
+  return new URL(resource).openStream();
+
+return new FileInputStream( new File(resource) );
+  }


RFC 2396 [0], section 3.1, Scheme Component suggests to

treat upper case letters as equivalent to lower case in scheme names (e.g., allow HTTP 
as well as http)


Also, can you elaborate what motivates the selection of only file:// 
and http://; as protocols? For instance, whereever HTTP is used the 
option of HTTPS isn't that far. FTP?


Would it maybe better match your intention to just always call 
URL.openStream() and fallback to the FileInputStream in the case the 
former method threw an exception (unknown protocol)?



Benjamin



[0] http://www.faqs.org/rfcs/rfc2396.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726880 - in /maven/mercury/trunk: mercury-ant/mercury-ant-tasks/ mercury-ant/mercury-ant-tasks/src/main/java/org/apache/maven/mercury/ant/tasks/ mercury-ant/mercury-ant-tasks/src/main


Recorded in http://jira.codehaus.org/browse/MERCURY-59, will comply asahp

Benjamin Bentmann wrote:

Hi Oleg,


Author: ogusakov
Date: Mon Dec 15 16:04:14 2008
New Revision: 726880

URL: http://svn.apache.org/viewvc?rev=726880view=rev
Log:
[MERCURY-56] verification configuration for mercury ant tasks done, 
PGP unit test works on osx. Need test keyrings for other platforms.


[...]

@@ -30,7 +40,7 @@
 public class Config
 extends AbstractDataType
 {
-  private static final Language LANG = new DefaultLanguage( 
Config.class );
+  private static final Language _lang = new DefaultLanguage( 
Config.class );

  CollectionRepo _repos;
   @@ -178,6 +123,22 @@
 String _authid;
 String _proxyauthid;
 +boolean _readable = true;
+boolean _writeable = false;
++ListVerify _writeVerifiers;
+ListVerify _readVerifiers;
+
+public void setReadable( boolean readable )
+{
+  this._readable = readable;
+}
+
+@@ -207,6 +168,135 @@
 {
   return _dir != null;
 }
++public Verify createVerifywrite()
+{
+  if( _writeVerifiers == null )
+_writeVerifiers = new ArrayListVerify(2);


Please adopt our community conventions for Java code style [0, 1] 
which is usually as easy as importing the provided formatter configs 
into the IDE.


A consistent formatting eases reading/reviewing the code and more 
importantly simplifies contributing/patching.


Thanks


Benjamin


[0] 
http://maven.apache.org/developers/committer-environment.html#Maven_Code_Style 


[1] http://maven.apache.org/developers/conventions/code.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.x


On 16/12/2008, at 1:42 AM, Jason van Zyl wrote:

I think before the alpha-1 I don't think everyone is interested in  
getting spammed, but once the release is cut the goal is to keep the  
build on the grid machines in a perpetual working state so standard  
notification at that point should be fine.


With them up and running now I'd expect that the objective is already  
to keep them in a perpetual working state, so changing the  
notifications over would be helpful. There are some people changing  
the ITs even if they aren't changing trunk (for 2.0.10, f.e.) and it'd  
be good to know the effect that has.


Thanks,
Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.x

2008-12-16 Thread Arnaud HERITIER

Agreed. I would like that we simplify our notifications
I we could remove them from hud...@apache and continuum if we don't use them
anymore.

Arnaud

On Tue, Dec 16, 2008 at 9:40 PM, Brett Porter br...@apache.org wrote:

 On 16/12/2008, at 1:42 AM, Jason van Zyl wrote:

  I think before the alpha-1 I don't think everyone is interested in getting
 spammed, but once the release is cut the goal is to keep the build on the
 grid machines in a perpetual working state so standard notification at that
 point should be fine.


 With them up and running now I'd expect that the objective is already to
 keep them in a perpetual working state, so changing the notifications over
 would be helpful. There are some people changing the ITs even if they aren't
 changing trunk (for 2.0.10, f.e.) and it'd be good to know the effect that
 has.

 Thanks,

 Brett

 --
 Brett Porter
 br...@apache.org
 http://blogs.exist.com/bporter/


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: external components was: svn commit: r726521



On 16/12/2008, at 7:50 PM, Ralph Goers wrote:



On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote:



Also in the course of 6 months of development of the model-builder  
we have not had a single contribution from anyone else. Zero  
interest. So yes, it is easier to release elsewhere and that has  
allowed me to patch, test, release in rapid succession to try and  
get the alpha-1 to the point of release.




I wouldn't say zero interest. I simply have found it impossible to  
keep up with all the svn commits in all the various branches.  
Furthermore, a lot of stuff was being worked on in somewhat private  
branches. Unless they ask for collaboration I'm not going to go  
review stuff in someone's private sandbox until they call out and  
say it is ready for review before merging.


Yes, exactly.

I don't particularly care if the code is put somewhere else. The  
license allows it and I'm not particularly attached to my single  
trivial commit.


I do care if we start introducing dependencies from external sources  
without setting a higher barrier. If it were anything like Woodstox  
where it was pretty much baked and clear what to do if you have a  
problem then it'd be fine. But if it's going to be outside the project  
(particularly where some people don't have commit access) we can't  
chase snapshots. The situation with Modello and Plexus is not an ideal  
way to continue doing things given the chance to change, no matter how  
easy it is to get commit or how easy it is to get the whole chain of  
dependencies up in an IDE.


Even if the code of the model-builder is completely stable, it needs  
more work:
- there's no site or documentation to go with it (from what I can  
tell, all the documentation is in the PDF which is now in Maven)
- there's no issue tracker to report problems to (I found SPICE though  
it's not listed in the POM, but it doesn't have a component)
- there's no way to find out where it is going next or ask questions.  
That's either going to happen here (in which case, why move?), or need  
to be done privately with Shane (which is not scalable).


The fact that it was released (as 1.0) like that, without changing the  
packages or the license made it look to me like it was the right thing  
done at the wrong time for the wrong reasons.


Given that, it was just hard to tell what was going on - though it is  
helpful that it has been made clear that nothing else is going to be  
moved now.


Thanks,
Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Improving CI ITs



On 16/12/2008, at 11:51 AM, Jason van Zyl wrote:

By layering I think that a canonical system should be picked, say  
Ubuntu, and that should be a fast compile-only smoke test to look  
for breakages. If that works trigger the tests, if that works  
propagate to the grid, do the build and run the ITs. Then layer in  
plugin tests maybe daily. That may not be the perfect workflow and  
we should put this in the wiki.


+1, something like this sounds good.

Tom/John, I don't know how long it will take to finish the maven  
integration testing plugin and get all the nodes updated. But I can  
do the dirty trick that I did before which was the let the bootstrap  
feed into a predefined Maven installation location. I just want to  
get the ITs triggered correctly using the version of Maven built by  
the bootstrap.


I still don't quite get the approaches being used here. Can someone  
clear up all the pieces for me?


- we have deployment of the IT plugins to a repository even as  
snapshots, though I thought it was required to be pre-installed based  
on the bits below?
- maven-integration-tests checks out the ITs from trunk but how does  
that integrate with Hudson's existing SCM checks?
- Hudson plugins are meant to coordinate running with a version  
instead of requiring the above?


I agree there needs to be one standard way to do these things, but I'd  
like to understand the technical reasons for choosing the bootstrap,  
etc. over the unpack-and-run approach of maven-core-it-runner before  
it disappears completely. The only one I've heard described was the  
possibility of the IT artifacts in the repo being out of date, but  
that's irrelevant in a CI situation and they seem to be getting  
deployed above anyway.


To me, the approach is much more Maven-y by reusing the repository and  
ordering, and it's easy to understand. Where did it not address the  
needs in setting this up?


I also think it makes sense to release the integration tests that were  
used to verify a particular release of Maven so we always have that  
locked in. Otherwise as the ITs change, we have a different measure of  
what worked in 2.0.x and what didn't. The runner approach is much  
better suited to this rather than checking it out from a tag each time.


Benjamin, you've basically done all the work for the ITs so far. You  
think you might sketch out in the wiki what you think would be  
ideal? At this point I think we defer to you as you've been working  
on them so long.


Benjamin++ :)

Cheers,
Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: external components was: svn commit: r726521

2008-12-16 Thread Arnaud HERITIER

+1
It's too difficult to follow what it is done in 2.0.X, 2.X and 3.X in the
same time without working on it every day.

Arnaud

On Tue, Dec 16, 2008 at 9:50 AM, Ralph Goers ralph.go...@dslextreme.comwrote:


 On Dec 15, 2008, at 7:41 AM, Jason van Zyl wrote:



 Also in the course of 6 months of development of the model-builder we have
 not had a single contribution from anyone else. Zero interest. So yes, it is
 easier to release elsewhere and that has allowed me to patch, test, release
 in rapid succession to try and get the alpha-1 to the point of release.


 I wouldn't say zero interest. I simply have found it impossible to keep
 up with all the svn commits in all the various branches. Furthermore, a lot
 of stuff was being worked on in somewhat private branches. Unless they ask
 for collaboration I'm not going to go review stuff in someone's private
 sandbox until they call out and say it is ready for review before merging.

 Ralph


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: What will replace the @aggregator MOJO configuration?

I don't believe the doc covered pre-/post- lifecycle operations, just  
the @aggregator changes that were the initial discussion.


They'd probably need a new proposal. Perhaps something hooking into  
the model builder listening from the new work on trunk (just taking a  
wild stab in the dark, haven't looked at it since they were introduced).


- Brett

On 15/12/2008, at 8:11 PM, Stephen Connolly wrote:


2008/12/15 Brett Porter br...@apache.org



On 12/12/2008, at 6:57 AM, Barrie Treloar wrote:

On Fri, Dec 12, 2008 at 3:51 AM, Brian E. Fox bri...@reply.infinity.nu 


wrote:


I think most of these ideas are already covered in the lifecycle
proposal out there that john wrote.



Can you paste the link in please?



http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning

There are two linked docs at the bottom that are probably more  
relevant.




It's not clear to me from that proposal, how we could accommodate  
plugins

that need to update the pom...

For example, I'd like that versions-maven-plugin could work  
preemptively for

goals like update-parent...

Perhaps some mojos will need a way to run outside the lifecycle, or  
at least

signal that they could affect build plan determination somewhat... for
example, if I update the parent of some modules to a newer version,  
that

newer version may add/remove profiles, add/remove plugins, etc.

Perhaps that is covered in the Wiki, but it's just not clear to me

-Stephen





- Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Shaded Jars + Netbeans = confused Netbeans?

2008-12-16 Thread Lilianne E. Blaze

Hello,
Any ideas what could cause it?
Any hints, workarounds, anything?

Greetings, L

Lilianne E. Blaze wrote:
 Hello,
 (I already tried on users- list)
 
 I'm trying to make a jar containing x dependencies to be used as a
 single dependency, using Shade with the following options:
 
 createSourcesJartrue/createSourcesJar
 keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
 promoteTransitiveDependenciestrue/promoteTransitiveDependencies
 
 It seems ok, looks ok, works ok. _But_ - Netbeans doesn't seem to
 recognize it - code completion fails with package/class/symbol does not
 exist errors all over the place. Now I'm pretty much stuck. It could be
 a problem with Maven, could be with Netbeans, could be my (complete or
 partial) mistake with understanding how Maven makes / handles Shaded jars.
 
 I already submitted a report at
 http://www.netbeans.org/issues/show_bug.cgi?id=155091 , along with a
 simple project (3 projects, 2 classes) to demonstrate it.
 
 Greetings, thanks in advance, Lilianne
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r726848 - /maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml

Er, I can't deploy there :)


Is that setting necessary? It should be inherited from the parent so any CI
process that wants to deploy elsewhere can just
override distMgmtSnapshotsUrl from the command line, which I thought was how
it was being done for everything else.


Cheers,

Brett

2008/12/16 bri...@apache.org

 Author: brianf
 Date: Mon Dec 15 14:20:54 2008
 New Revision: 726848

 URL: http://svn.apache.org/viewvc?rev=726848view=rev
 Log:
 deploy the plugins to a repo

 Modified:

  maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml

 Modified:
 maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml
 URL:
 http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml?rev=726848r1=726847r2=726848view=diff

 ==
 ---
 maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml
 (original)
 +++
 maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml
 Mon Dec 15 14:20:54 2008
 @@ -64,6 +64,23 @@
 developerConnectionscm:svn:
 https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-it-support/core-it-plugins
 /developerConnection
 url
 http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-it-support/core-it-plugins
 /url
   /scm
 +  distributionManagement
 +repository
 +  idmaven.it/id
 +  nameApache Maven Integration Testing Repository/name
 +  url
 http://repository.sonatype.org/content/repositories/maven-it-plugins/url
 +/repository
 +snapshotRepository
 +  idmaven.it/id
 +  name${distMgmtSnapshotsName}/name
 +  url${distMgmtSnapshotsUrl}/url
 +/snapshotRepository
 +  /distributionManagement
 +
 +  properties
 +distMgmtSnapshotsNameApache Maven Integration Testing Snapshot
 Repository/distMgmtSnapshotsName
 +distMgmtSnapshotsUrl
 http://repository.sonatype.org/content/repositories/maven-it-plugin-snapshots
 /distMgmtSnapshotsUrl
 +  /properties

   build
 pluginManagement





-- 
Brett Porter
http://blogs.exist.com/bporter/

sometimes too much help is not helping - r725533


Brett,

Please don't change the code you don't understand without, at least, 
consulting people who work on it.


I lost entire day between yesterday and today, trying to understand why 
my unit tests suddenly stopped working. They traced to your commit 
r725533 which emptied jar files in mercury-ant-tasks! Unit tests were 
using those jars to compile test code.


I appreciate the help, but help that adds value to the project, not 
hinders it. Take, for example, Ben - he found a bug and posted the 
solution in jira, because he was not sure that it can break tests. It 
did break them, but together we found the solution (btw - he was right).


Our team is very responsive, and posting problem in jira usually gets 
them resolved.


Thanks,
Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: sometimes too much help is not helping - r725533

On 17/12/2008, at 11:03 AM, Oleg Gusakov wrote:

Brett,

Please don't change the code you don't understand without, at least,
consulting people who work on it.

I did try... http://markmail.org/message/ifkbjf3rb24z3wvb

I have a good understanding of how the code works. Outside of the
Jetty client, I think I may be the only person (with the possible
exception of Jason) that has given it a decent look over at this
point. I'm still seeking you're enlightenment on the pieces I didn't
understand: http://markmail.org/message/tibxv4f7di2caj2y, and am still
looking forward to your response.

I lost entire day between yesterday and today, trying to understand
why my unit tests suddenly stopped working. They traced to your
commit r725533 which emptied jar files in mercury-ant-tasks! Unit
tests were using those jars to compile test code.

I'm sorry you lost some time investigating it, but I made every
attempt to do this properly.

At the time I made the change, I cleaned out the checkout and did a
build without getting any test errors. This was confirmed by the grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/

It appears your change to test using compilation was only checked in
afterwards. I'm afraid I'm still working on my ability to predict the
future :)

Certainly if it had been a functional change I'd have spent more time
in consultation as you suggested. The example you gave from Benjamin
is certainly a good way for things to work. We all need to tread
lightly in unfamiliar territory, and I understand that. I have no
desire to look like an idiot through inexperience if I can avoid it.

Anyway, thanks for fixing up the size of the test repo even in the
reversion. I do appreciate it.

- Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: Improving CI ITs

- we have deployment of the IT plugins to a repository even as  
snapshots, though I thought it was required to be pre-installed based  
on the bits below?
Everything is ready now for them to be deployed as releases to a repo
that is separate from Central to avoid the clashes that people saw
before.

but I'd  
like to understand the technical reasons for choosing the bootstrap,  
etc. over the unpack-and-run approach of maven-core-it-runner before  
it disappears completely. The only one I've heard described was the  
possibility of the IT artifacts in the repo being out of date, but  
that's irrelevant in a CI situation and they seem to be getting  
deployed above anyway.

John and I came up with this solution because it was frustrating always
trying to chase either the maven snapshot or the it snapshot when things
were committed. By putting it into the bootstrap, we now have a single
execution that builds both Maven and the Its and then run them together.
A single atomic unit. I still see some value in the unpack-and-run
approach personally but I also think having multiple ways to run Its is
annoying to explain to new users. I think the bootstrap one is easy.

I also think it makes sense to release the integration tests that were

used to verify a particular release of Maven so we always have that  
locked in. Otherwise as the ITs change, we have a different measure of

what worked in 2.0.x and what didn't. The runner approach is much  
better suited to this rather than checking it out from a tag each time.

Agreed. 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: svn commit: r726848 - /maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom.xml

The snapshots are coming from CI. The releases will as well. Once Apache
gets LDAP setup, hopefully we can tap into it to make it easier. The
current security model isn't very scalable.

-Original Message-
From: Brett Porter [mailto:br...@porterclan.net] 
Sent: Tuesday, December 16, 2008 6:26 PM
To: dev@maven.apache.org
Subject: Re: svn commit: r726848 -
/maven/core-integration-testing/trunk/core-it-support/core-it-plugins/po
m.xml

Er, I can't deploy there :)


Is that setting necessary? It should be inherited from the parent so any
CI
process that wants to deploy elsewhere can just
override distMgmtSnapshotsUrl from the command line, which I thought was
how
it was being done for everything else.


Cheers,

Brett

2008/12/16 bri...@apache.org

 Author: brianf
 Date: Mon Dec 15 14:20:54 2008
 New Revision: 726848

 URL: http://svn.apache.org/viewvc?rev=726848view=rev
 Log:
 deploy the plugins to a repo

 Modified:


maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom
.xml

 Modified:

maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom
.xml
 URL:

http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-i
t-support/core-it-plugins/pom.xml?rev=726848r1=726847r2=726848view=di
ff



==
 ---

maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom
.xml
 (original)
 +++

maven/core-integration-testing/trunk/core-it-support/core-it-plugins/pom
.xml
 Mon Dec 15 14:20:54 2008
 @@ -64,6 +64,23 @@
 developerConnectionscm:svn:

https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/co
re-it-support/core-it-plugins
 /developerConnection
 url

http://svn.apache.org/viewvc/maven/core-integration-testing/trunk/core-i
t-support/core-it-plugins
 /url
   /scm
 +  distributionManagement
 +repository
 +  idmaven.it/id
 +  nameApache Maven Integration Testing Repository/name
 +  url

http://repository.sonatype.org/content/repositories/maven-it-plugins/ur
l
 +/repository
 +snapshotRepository
 +  idmaven.it/id
 +  name${distMgmtSnapshotsName}/name
 +  url${distMgmtSnapshotsUrl}/url
 +/snapshotRepository
 +  /distributionManagement
 +
 +  properties
 +distMgmtSnapshotsNameApache Maven Integration Testing Snapshot
 Repository/distMgmtSnapshotsName
 +distMgmtSnapshotsUrl

http://repository.sonatype.org/content/repositories/maven-it-plugin-snap
shots
 /distMgmtSnapshotsUrl
 +  /properties

   build
 pluginManagement





-- 
Brett Porter
http://blogs.exist.com/bporter/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: sometimes too much help is not helping - r725533


Brett,

Trust me, I don't enjoy this discussion no more that you, but I have to 
respond.


Brett Porter wrote:
I'm sorry you lost some time investigating it, but I made every 
attempt to do this properly.


At the time I made the change, I cleaned out the checkout and did a 
build without getting any test errors. This was confirmed by the grid: 
https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/


It appears your change to test using compilation was only checked in 
afterwards. I'm afraid I'm still working on my ability to predict the 
future :)
This statement suggests that I am a dumb coder, who submits tons of jars 
to SVN for the pleasure of just having them there. I admit that I did 
not commit the tests using those jars right away.


But give me some credit: everything has a reason. And if this reason is 
not clear - ask, don't assume you know everything and can improve 
without knowing. I did acknowledge your suggestion about the size of 
test repo, and started fixing it. If you would have just suggested the 
solution, provided a script in jira - that would only raise a lot of 
gratitude.


But hindering a pre-alpha quality project by assuming things and 
changing still unstable data, this is simply not fair. Losing a day over 
such a trivial matter - I simply did not expect anyone to do such a thing.


I apologize if this sounds harsh, but believe me - the sole purpose is 
to improve our process, make sure that this does not happen in the future.


So the proposal is: change the rules to say the following: if you don't 
work on an actively developed project - don't start modifying it without 
consulting the team, working on it. If you do find a bug or improvement 
- communicate with developers via issue tracking system and other means 
This is not predicting the future - just common sense.


Thanks,
Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: sometimes too much help is not helping - r725533


Oleg and I sorted out the misunderstanding offline. It's all good.

- Brett

On 17/12/2008, at 2:19 PM, Oleg Gusakov wrote:


Brett,

Trust me, I don't enjoy this discussion no more that you, but I have  
to respond.


Brett Porter wrote:
I'm sorry you lost some time investigating it, but I made every  
attempt to do this properly.


At the time I made the change, I cleaned out the checkout and did a  
build without getting any test errors. This was confirmed by the  
grid: https://grid.sonatype.org/ci/view/Mercury/job/mercury-ant/6/


It appears your change to test using compilation was only checked  
in afterwards. I'm afraid I'm still working on my ability to  
predict the future :)
This statement suggests that I am a dumb coder, who submits tons of  
jars to SVN for the pleasure of just having them there. I admit that  
I did not commit the tests using those jars right away.


But give me some credit: everything has a reason. And if this reason  
is not clear - ask, don't assume you know everything and can improve  
without knowing. I did acknowledge your suggestion about the size of  
test repo, and started fixing it. If you would have just suggested  
the solution, provided a script in jira - that would only raise a  
lot of gratitude.


But hindering a pre-alpha quality project by assuming things and  
changing still unstable data, this is simply not fair. Losing a day  
over such a trivial matter - I simply did not expect anyone to do  
such a thing.


I apologize if this sounds harsh, but believe me - the sole purpose  
is to improve our process, make sure that this does not happen in  
the future.


So the proposal is: change the rules to say the following: if you  
don't work on an actively developed project - don't start modifying  
it without consulting the team, working on it. If you do find a bug  
or improvement - communicate with developers via issue tracking  
system and other means This is not predicting the future - just  
common sense.


Thanks,
Oleg


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Improving CI ITs



On 17/12/2008, at 1:59 PM, Brian E. Fox wrote:


- we have deployment of the IT plugins to a repository even as
snapshots, though I thought it was required to be pre-installed based
on the bits below?

Everything is ready now for them to be deployed as releases to a repo
that is separate from Central to avoid the clashes that people saw
before.


Great.

I wonder, is the test still valuable enough if we kick off a Jetty  
instance and host the repo locally rather than relying on an external  
resource being up/accessible?


Upsides: that would also help with avoiding repo manager interference  
in the results, tests would be faster
Downsides: a bit more complicated test set up. If it were started from  
the POM, it disadvantages IDE running, if it were started from the  
tests it adds a bit of complication in there.


WDYT?

John and I came up with this solution because it was frustrating  
always
trying to chase either the maven snapshot or the it snapshot when  
things

were committed. By putting it into the bootstrap, we now have a single
execution that builds both Maven and the Its and then run them  
together.

A single atomic unit. I still see some value in the unpack-and-run
approach personally but I also think having multiple ways to run Its  
is

annoying to explain to new users. I think the bootstrap one is easy.


It might be nice to investigate a CI plugin that can always keep those  
builds together and take another look in the future.


There are still some things that make me a bit uneasy about it:
- the dummy POM (2.0.x)... seems like this should be functionality  
right in the top level POM or a proper module.
- it seems awkward to work on , you'd need to revert to running mvn  
from your working directory for the IT instead since you have to  
commit for the other changes to take, or reconfigure itDir

- it's sad that the main way to build Maven is not with Maven :)




I also think it makes sense to release the integration tests that  
were



used to verify a particular release of Maven so we always have that
locked in. Otherwise as the ITs change, we have a different measure  
of



what worked in 2.0.x and what didn't. The runner approach is much
better suited to this rather than checking it out from a tag each  
time.


Agreed.


Cool. I see this change still supports that through a tagged checkout.  
Will we release the ITs for 2.0.10, or is that too soon?


Cheers,
Brett

--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

RE: POM construction specification

The only difference between a parent project and a mixin is that the mixin is
abstract (not a complete model).

Is that really true? A Mixin should be deployed to the repository, which 
essentially means it needs to be complete enough to id and thus a complete 
model. It should be deployed as a classified artifact though to avoid mixing in 
the instructions for building/deploying from those that are intended to be 
mixed in. (ie the mixin's pom is separate)

3.1: what about multiple parents? I assume it's the first one, but should be 
explicit in the spec.
3.2: section is blank but contentious based on current behavior and the 
in-ability to use properties and inheritance together.
3.3: I don't understand this statement. A child always overrides the parent or 
joins with it. Are you saying that the parent wins here? Also 
pluginRepositories is going away soon. In general why can't the things listed 
here be extended?
3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists 
the group? (group/artifact/version ones should be skipped, but if you're 
relocating everything in a group, it would make sense to do this at the top of 
that group tree pom)
3.5 I agree with Ralph here that Final is the wrong term. Private is more 
appropriate.

I started this in the morning and didn't finish yet so sending what I have.

-Original Message-
From: Ralph Goers [mailto:ralph.go...@dslextreme.com] 
Sent: Tuesday, December 16, 2008 3:59 AM
To: Maven Developers List
Subject: Re: POM construction specification


On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:

 This is for the general population but I'm nudging you Ralph because  
 I know that you want to make some changes for not requiring the  
 version in the parent element.



You should have warned me to have a glass of wine before attempting to  
read all these math notations. :-) Or put a link to 
http://en.wikipedia.org/wiki/Table_of_mathematical_symbols 
  for those of use who haven't had a math class in the last 25 years.  
The funny thing is, I have a B.S. in Physics. Man it has been a long  
time. :-(

Comments:
1.1 Mentions there are 465 model properties. An appendix should list  
them. Specifically, I'd like to see provides listed along with the  
project's groupId, artifactId and version and requires in the  
dependency declaration - or whatever other way that kind of metadata  
will be added.
2.1  2.2 Is all this simply stating that the closest definition wins  
and when two or more are equally close then the first one wins?
2.4 The only definition of mixin is The only diﬀerence between a  
parent pro ject and a mixin is that the mixin is
abstract (not a complete model). That sure leaves a lot to the  
imagination. And what exactly makes a model incomplete? Isn't a pom  
with just a dependencyManagement complete? I also found myself  
wondering that even though it might be possible to support extending  
multiple parents, should we? I could see allowing only one parent but  
multiple mixins.
3.1 Even though may be obvious, it should explicitly state that  
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least be  
set from project.parent.groupIdt)?
3.4 The footnote says the artifactId can be inherited from the parent.  
That makes no sense to me. Every pom should represent a unique  
artifact or at least a unique pom.
3.5 I found the statement This will mark the container as ﬁnal, thus  
preventing inheritance: as misleading. In java terms this would mean  
a child pom attempting to define the same plugin would fail. The  
setting of inherited to false in the sample indicates to me the  
opposite, the plugin definition in the parent is invisible to the  
child.  Here is a question though. If A overrides a plugin defined in  
the super pom and has inherited true, then B extends A and overrides  
the plugin and sets inherited to false, what will C which extends from  
B get? It should see the definition in A.  Or does this whole section  
mean that the plugin definition in B inherits nothing from A?
3.8 the element will be inherited. Unless the parent definition has  
inheritedfalse/inherited ?

I don't see anything in here about being able to locate a parent  
without having to know its version. Within the scope of the purpose of  
this document it may not be relevant, but at the very least somewhere  
in section 3 it should state that if a parent is specified than which  
elements are required.

I hope this was the kind of feedback you were looking for.
Ralph




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

mng-3898 in 2.0.10?

Herve,

I was just in the process of staging 2.0.10 when I noticed that you
bumped the Modello version from alpha-13 to alpha-22. I didn't see this
raised as an issue in any of the RCs and it concerns me to make such a
jump this late in the game. Once we start the RCs we should only be
fixing regressions reported against the RCs...it looks like this was a
regression and thus qualifies but some discussion about the relative
merits of the fix vs any potential destabilizing should take place. 

 

I'll roll back the stage and produce another RC for this.

 

--Brian

[2.0.10 RC6] please test

Hello,
Thanks everyone for sticking with us this far. I have high hopes of this
being the last RC.

This RC fixes MNG-3898 and updates the default plugin versions in the
super pom. You can see the changes to the super pom and specific
versions used here:
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.10-RC/m
aven-project/src/main/resources/org/apache/maven/project/pom-4.0.0.xml?r
1=708789r2=726765diff_format=h

Here's the list of issues fixed in 2.0.10 (updated to remove the wagon
fixes that were rolled back):

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14112styleName
=HtmlprojectId=10500Create=Create

And I've staged RC-6 here:

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.10-RC6/



Please try it out and see if we have any remaining regressions over
2.0.9.

Thanks,
Brian


--
Brian Fox
Apache Maven PMC
http://blogs.sonatype.com/brian/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Problem using velocity component

2008-12-16 Thread Alfie Kirkpatrick

Hi, I am attempting to write a plugin that uses Velocity to template
some config files. I have been developing the plugin using m2eclipse
embedded maven runtime and it works fine. But it gives a NPE when I run
it in maven standalone, even with the 2.1M1 release.

 

I have the following in my class:

 

  /**

   * @component

   */

  protected VelocityComponent velocityComponent;

 

The line giving the NPE is:

 

  Template template =
velocityComponent.getEngine().getTemplate(/+templateName+.vm);

 

When running standalone the velocityComponent is initialised with a
DefaultVelocityComponent but with a null engine, so getTemplate gives
the NPE.

 

Am struggling to understand if I'm doing this correctly and why it
should work in maven embedder (in m2eclipse) but not standalone?

 

As an aside, my class implements org.codehaus.plexus.logging.LogEnabled
and running with maven embedder, the enableLogging method is called with
a PlexusLoggerAdapter, but running standalone this method is not called.
Can't help feeling this is related...

 

Any help much appreciated!

 

Regards, Alfie.

Re: Problem using velocity component

2008-12-16 Thread Jason van Zyl

If you jar up your plugin project I'll take a look. Create a JIRA  
issue and attach the project and I'll see it.


On 16-Dec-08, at 6:34 PM, Alfie Kirkpatrick wrote:


Hi, I am attempting to write a plugin that uses Velocity to template
some config files. I have been developing the plugin using m2eclipse
embedded maven runtime and it works fine. But it gives a NPE when I  
run

it in maven standalone, even with the 2.1M1 release.



I have the following in my class:



 /**

  * @component

  */

 protected VelocityComponent velocityComponent;



The line giving the NPE is:



 Template template =
velocityComponent.getEngine().getTemplate(/+templateName+.vm);



When running standalone the velocityComponent is initialised with a
DefaultVelocityComponent but with a null engine, so getTemplate gives
the NPE.



Am struggling to understand if I'm doing this correctly and why it
should work in maven embedder (in m2eclipse) but not standalone?



As an aside, my class implements  
org.codehaus.plexus.logging.LogEnabled
and running with maven embedder, the enableLogging method is called  
with
a PlexusLoggerAdapter, but running standalone this method is not  
called.

Can't help feeling this is related...



Any help much appreciated!



Regards, Alfie.



Thanks,

Jason

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

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: POM construction specification

The way I read 3.4  the parent does not win. The child declaration  
simply overrides the parent. Consider project developers. If specified  
in a child then only those developers participate in this subproject.  
developers specified in the parent are ignored. Whether it makes sense  
to do it that way is a different question.


Ralph

On Dec 16, 2008, at 8:32 PM, Brian E. Fox wrote:

The only difference between a parent project and a mixin is that  
the mixin is

abstract (not a complete model).

Is that really true? A Mixin should be deployed to the repository,  
which essentially means it needs to be complete enough to id and  
thus a complete model. It should be deployed as a classified  
artifact though to avoid mixing in the instructions for building/ 
deploying from those that are intended to be mixed in. (ie the  
mixin's pom is separate)


3.1: what about multiple parents? I assume it's the first one, but  
should be explicit in the spec.
3.2: section is blank but contentious based on current behavior and  
the in-ability to use properties and inheritance together.
3.3: I don't understand this statement. A child always overrides the  
parent or joins with it. Are you saying that the parent wins here?  
Also pluginRepositories is going away soon. In general why can't the  
things listed here be extended?
3.4 shouldn't project.distMgt.relocation be inherited if the  
relocation lists the group? (group/artifact/version ones should be  
skipped, but if you're relocating everything in a group, it would  
make sense to do this at the top of that group tree pom)
3.5 I agree with Ralph here that Final is the wrong term. Private is  
more appropriate.


I started this in the morning and didn't finish yet so sending what  
I have.


-Original Message-
From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Sent: Tuesday, December 16, 2008 3:59 AM
To: Maven Developers List
Subject: Re: POM construction specification


On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:


This is for the general population but I'm nudging you Ralph because
I know that you want to make some changes for not requiring the
version in the parent element.




You should have warned me to have a glass of wine before attempting to
read all these math notations. :-) Or put a link to 
http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
 for those of use who haven't had a math class in the last 25 years.
The funny thing is, I have a B.S. in Physics. Man it has been a long
time. :-(

Comments:
1.1 Mentions there are 465 model properties. An appendix should list
them. Specifically, I'd like to see provides listed along with the
project's groupId, artifactId and version and requires in the
dependency declaration - or whatever other way that kind of metadata
will be added.
2.1  2.2 Is all this simply stating that the closest definition wins
and when two or more are equally close then the first one wins?
2.4 The only definition of mixin is The only diﬀerence between a
parent pro ject and a mixin is that the mixin is
abstract (not a complete model). That sure leaves a lot to the
imagination. And what exactly makes a model incomplete? Isn't a pom
with just a dependencyManagement complete? I also found myself
wondering that even though it might be possible to support extending
multiple parents, should we? I could see allowing only one parent but
multiple mixins.
3.1 Even though may be obvious, it should explicitly state that
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least be
set from project.parent.groupIdt)?
3.4 The footnote says the artifactId can be inherited from the parent.
That makes no sense to me. Every pom should represent a unique
artifact or at least a unique pom.
3.5 I found the statement This will mark the container as ﬁnal, thus
preventing inheritance: as misleading. In java terms this would mean
a child pom attempting to define the same plugin would fail. The
setting of inherited to false in the sample indicates to me the
opposite, the plugin definition in the parent is invisible to the
child.  Here is a question though. If A overrides a plugin defined in
the super pom and has inherited true, then B extends A and overrides
the plugin and sets inherited to false, what will C which extends from
B get? It should see the definition in A.  Or does this whole section
mean that the plugin definition in B inherits nothing from A?
3.8 the element will be inherited. Unless the parent definition has
inheritedfalse/inherited ?

I don't see anything in here about being able to locate a parent
without having to know its version. Within the scope of the purpose of
this document it may not be relevant, but at the very least somewhere
in section 3 it should state that if a parent is specified than which
elements are required.

I hope this was the kind of feedback you were looking for.
Ralph




-
To unsubscribe,

Re: POM construction specification

I fixed some typos - is it ok to regenerate the PDF? (mine comes out  
slightly different on the Mac but it's all there AFAICT).


Just to add to what Brian and Ralph have already said:

3.1 - I think we have to knock multiple inheritance out at this stage,  
even if it is noted as a possibility for general model building, I  
don't think it's appropriate for the Maven rules.
3.2 - We should just define this by the current behaviour IMO, then  
look at how we fix it going forward (See below on versioning)

3.3 - I had the same confusion as Brian. Why are collections not joined?

Some more things:

1.1 - mentioned this before, but should be use a valid URI that  
perhaps matches the POM namespace? http://maven.apache.org/POM/...
2.2 - I didn't see anything that says that in a set, a property should  
overwrite a previous one if it already exists (and define how equality  
is measured)?
2.2 - I think map handling needs to be defined for the same reason so  
that duplicate keys can be merged

3.6.2 - why is the parent artifact ID listed in the (1-3) section?
3.6.2 - are join, nop and delete in a different order to the following  
bullets?
3.8 - how are properties represented by XML elements in the current  
schema handled in the URI? the combine technique is listed as a  
property, but is the attribute actually recognised as something  
different?

4.1 - refers to 3.4, but I think it means 3.6
4.1 - how is plugin configuration handled? it only details the  
combination of the artifact portion. Should executions be explicitly  
forbidden in the management just for clarity?

5.1.1 - timestamp format should be described?
5.1.1 - is the basedir absolute?
5.1.2 - this seems too implementation specific
5.1.4 - this is a self-referential definition. I don't think the  
difference between types of properties is clear enough - maybe  
defining system as dominant and environment as recessive is more  
descriptive

5.2.2 - need to list what the build directory elements are
5.3 - profiles are not addressed elsewhere - should their processing  
as an additional form of inheritance be described?


Versioning...

I really would like to understand how this is going to work. My  
impression is the following:
- this document would be locked down to current behaviour as 4.0.0  
(warts and all)
- a new version of the document would make addition and changes, and  
would be a completely new rule set

- the URIs would be the same, not including a version.
- to operate on two versions of the model, the older would be upgraded  
to the new one first by a mapping of properties from one to the other.  
If the mapping was complicated it might need to be handled by an  
external converter - but the inheritance should always operate on two  
models of the same version. The problem here is that you can no longer  
honour some of the older rules from inherited POMs - but that may not  
be a serious consequence.


Is this what you expect?

BTW, should we now delete the wiki page that held basically the same  
info?


Cheers,
Brett

On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:

The only difference between a parent project and a mixin is that  
the mixin is

abstract (not a complete model).

Is that really true? A Mixin should be deployed to the repository,  
which essentially means it needs to be complete enough to id and  
thus a complete model. It should be deployed as a classified  
artifact though to avoid mixing in the instructions for building/ 
deploying from those that are intended to be mixed in. (ie the  
mixin's pom is separate)


3.1: what about multiple parents? I assume it's the first one, but  
should be explicit in the spec.
3.2: section is blank but contentious based on current behavior and  
the in-ability to use properties and inheritance together.
3.3: I don't understand this statement. A child always overrides the  
parent or joins with it. Are you saying that the parent wins here?  
Also pluginRepositories is going away soon. In general why can't the  
things listed here be extended?
3.4 shouldn't project.distMgt.relocation be inherited if the  
relocation lists the group? (group/artifact/version ones should be  
skipped, but if you're relocating everything in a group, it would  
make sense to do this at the top of that group tree pom)
3.5 I agree with Ralph here that Final is the wrong term. Private is  
more appropriate.


I started this in the morning and didn't finish yet so sending what  
I have.


-Original Message-
From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Sent: Tuesday, December 16, 2008 3:59 AM
To: Maven Developers List
Subject: Re: POM construction specification


On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:


This is for the general population but I'm nudging you Ralph because
I know that you want to make some changes for not requiring the
version in the parent element.




You should have warned me to have a glass of wine before attempting to
read all these math notations. :-) Or

Re: POM construction specification

2008-12-16 Thread Shane Isbell

Comments in line

On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers ralph.go...@dslextreme.comwrote:


 On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:

  This is for the general population but I'm nudging you Ralph because I
 know that you want to make some changes for not requiring the version in the
 parent element.



 You should have warned me to have a glass of wine before attempting to read
 all these math notations. :-) Or put a link to
 http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of
 use who haven't had a math class in the last 25 years. The funny thing is, I
 have a B.S. in Physics. Man it has been a long time. :-(

 Comments:
 2.1  2.2 Is all this simply stating that the closest definition wins and
 when two or more are equally close then the first one wins?

2.1 covers the high level processing starting with the transformation from
the original model (XML) to the canonical model and going through
interpolation and other rules.
2.2 does cover which property wins for: singletons, collections and sets.

 2.4 The only definition of mixin is The only diﬀerence between a parent
 pro ject and a mixin is that the mixin is
 abstract (not a complete model). That sure leaves a lot to the
 imagination. And what exactly makes a model incomplete? Isn't a pom with
 just a dependencyManagement complete? I also found myself wondering that
 even though it might be possible to support extending multiple parents,
 should we? I could see allowing only one parent but multiple mixins.

A mixin wouldn't be required to have things like project.version or
project.groupId. This makes the model abstract. From the framework's
perspective, it's all just a linear set of complete or incomplete models
Whether it's considered multiple parents or a chains of inherited parents,
it's all processed the same. My take is that if it's a complete model, it's
actually just another parent. We are really just dealing with definitions
here, it doesn't change processing. We can discuss more on what the
definitions should be.


 3.4 Why can't the groupId be inherited from its parent (or at least be set
 from project.parent.groupIdt)?

Technically, it isn't inherited from the parent. If groupId is not defined,
the project.parent.groupId is used (footnote 1).


 3.4 The footnote says the artifactId can be inherited from the parent. That
 makes no sense to me. Every pom should represent a unique artifact or at
 least a unique pom.

I'll change the spec doc. But when we throw in mixins, it's not exactly
clear whether things like artifactId shouldn't be inherited. This will be
one area we will need to discuss as we move toward mixins.


 3.5 I found the statement This will mark the container as ﬁnal, thus
 preventing inheritance: as misleading. In java terms this would mean a
 child pom attempting to define the same plugin would fail. The setting of
 inherited to false in the sample indicates to me the opposite, the plugin
 definition in the parent is invisible to the child.  Here is a question
 though. If A overrides a plugin defined in the super pom and has inherited
 true, then B extends A and overrides the plugin and sets inherited to false,
 what will C which extends from B get? It should see the definition in A.  Or
 does this whole section mean that the plugin definition in B inherits
 nothing from A?

You raise some good points. I was struggling a bit with the terms here. I'll
give it some more thought.


 3.8 the element will be inherited. Unless the parent definition has
 inheritedfalse/inherited ?

 I don't see anything in here about being able to locate a parent without
 having to know its version. Within the scope of the purpose of this document
 it may not be relevant, but at the very least somewhere in section 3 it
 should state that if a parent is specified than which elements are required.

Locating parents fell a bit outside of this original spec, but I think it's
worth adding something about how this is to be handled. We would need some
rule that says a parent.version is not required. And also how to cover the
situation where project.parent.version and project.version are both missing.

Thanks,
Shane

Re: POM construction specification

2008-12-16 Thread Jason van Zyl

On 16-Dec-08, at 3:58 AM, Ralph Goers wrote:

On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote:

This is for the general population but I'm nudging you Ralph
because I know that you want to make some changes for not requiring
the version in the parent element.

You should have warned me to have a glass of wine before attempting
to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols
for those of use who haven't had a math class in the last 25 years.
The funny thing is, I have a B.S. in Physics. Man it has been a long
time. :-(

We should definitely add them to the appendix. If you actually look at
the implementation the parsers are domain specific and they produce
the set of model properties. I think Shane did what was correct in
that he focused on a concrete implementation and got it working. So
right now the domain specific parser is hand-written. There is no
reason that this parser cannot be generated with modello and when we
do that we can use the descriptions in the modello model to generate
an appendix with a description of each property.

2.1 2.2 Is all this simply stating that the closest definition
wins and when two or more are equally close then the first one wins?

Let me add actual examples with POMs and I think it will be more clear.

2.4 The only definition of mixin is The only diﬀerence between a
parent pro ject and a mixin is that the mixin is
abstract (not a complete model). That sure leaves a lot to the
imagination. And what exactly makes a model incomplete? Isn't a
pom with just a dependencyManagement complete? I also found myself
wondering that even though it might be possible to support extending
multiple parents, should we? I could see allowing only one parent
but multiple mixins.
3.1 Even though may be obvious, it should explicitly state that
artifactId is always required.
3.4 Why can't the groupId be inherited from its parent (or at least
be set from project.parent.groupIdt)?

It can be. The Maven POMs exhibit this property and it works fine so
I'll fix that.

3.4 The footnote says the artifactId can be inherited from the
parent. That makes no sense to me. Every pom should represent a
unique artifact or at least a unique pom.

Yup.

3.5 I found the statement This will mark the container as ﬁnal,
thus preventing inheritance: as misleading. In java terms this
would mean a child pom attempting to define the same plugin would
fail. The setting of inherited to false in the sample indicates to
me the opposite, the plugin definition in the parent is invisible to
the child. Here is a question though. If A overrides a plugin
defined in the super pom and has inherited true, then B extends A
and overrides the plugin and sets inherited to false, what will C
which extends from B get? It should see the definition in A. Or
does this whole section mean that the plugin definition in B
inherits nothing from A?
3.8 the element will be inherited. Unless the parent definition
has inheritedfalse/inherited ?

I don't see anything in here about being able to locate a parent
without having to know its version. Within the scope of the purpose
of this document it may not be relevant, but at the very least
somewhere in section 3 it should state that if a parent is specified
than which elements are required.

I think if it has anything to do with POM construction then we need to
include it in this document.

I hope this was the kind of feedback you were looking for.

This is great feedback. I'll get this converted into Confluence by the
end of the week and then it will be easier to collaborate. Shane also
reversed engineered the rules because nothing was ever documented as
it grew organically. I think a few rounds of doing this where we
clarify and the rules and we'll be in a lot better shape. I have
started a POM construction test suite which will act as a validation
for the specification which will be complete by alpha-2. For alpha-1 I
had the goal of some specific builds working to get the ball rolling.
The rigor will start after alpha-2 which combined with some of the
integration testing tools we have I think will ensure we go forward
and never backward again.

Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Thanks,

Jason

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

Re: POM construction specification

2008-12-16 Thread Jason van Zyl



On 17-Dec-08, at 1:27 AM, Brett Porter wrote:

I fixed some typos - is it ok to regenerate the PDF? (mine comes out  
slightly different on the Mac but it's all there AFAICT).


Just to add to what Brian and Ralph have already said:

3.1 - I think we have to knock multiple inheritance out at this  
stage, even if it is noted as a possibility for general model  
building, I don't think it's appropriate for the Maven rules.
3.2 - We should just define this by the current behaviour IMO, then  
look at how we fix it going forward (See below on versioning)


That' s all we're doing. The general mechanism is built into the  
builder for multiple inheritance the our constrained use only uses the  
super pom, but mixins are also inherited models. It was hard enough to  
sift backward and try and capture what it does and as I mentioned  
before I don't see any real changes being made to behavior until at  
least alpha-3.




3.3 - I had the same confusion as Brian. Why are collections not  
joined?


Some more things:

1.1 - mentioned this before, but should be use a valid URI that  
perhaps matches the POM namespace? http://maven.apache.org/POM/...
2.2 - I didn't see anything that says that in a set, a property  
should overwrite a previous one if it already exists (and define how  
equality is measured)?
2.2 - I think map handling needs to be defined for the same reason  
so that duplicate keys can be merged

3.6.2 - why is the parent artifact ID listed in the (1-3) section?
3.6.2 - are join, nop and delete in a different order to the  
following bullets?
3.8 - how are properties represented by XML elements in the current  
schema handled in the URI? the combine technique is listed as a  
property, but is the attribute actually recognised as something  
different?

4.1 - refers to 3.4, but I think it means 3.6
4.1 - how is plugin configuration handled? it only details the  
combination of the artifact portion. Should executions be explicitly  
forbidden in the management just for clarity?

5.1.1 - timestamp format should be described?
5.1.1 - is the basedir absolute?
5.1.2 - this seems too implementation specific
5.1.4 - this is a self-referential definition. I don't think the  
difference between types of properties is clear enough - maybe  
defining system as dominant and environment as recessive is more  
descriptive

5.2.2 - need to list what the build directory elements are
5.3 - profiles are not addressed elsewhere - should their processing  
as an additional form of inheritance be described?


Versioning...

I really would like to understand how this is going to work. My  
impression is the following:
- this document would be locked down to current behaviour as 4.0.0  
(warts and all)
- a new version of the document would make addition and changes, and  
would be a completely new rule set

- the URIs would be the same, not including a version.
- to operate on two versions of the model, the older would be  
upgraded to the new one first by a mapping of properties from one to  
the other. If the mapping was complicated it might need to be  
handled by an external converter - but the inheritance should always  
operate on two models of the same version. The problem here is that  
you can no longer honour some of the older rules from inherited POMs  
- but that may not be a serious consequence.


Is this what you expect?

BTW, should we now delete the wiki page that held basically the same  
info?


Cheers,
Brett

On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:

The only difference between a parent project and a mixin is that  
the mixin is

abstract (not a complete model).

Is that really true? A Mixin should be deployed to the repository,  
which essentially means it needs to be complete enough to id and  
thus a complete model. It should be deployed as a classified  
artifact though to avoid mixing in the instructions for building/ 
deploying from those that are intended to be mixed in. (ie the  
mixin's pom is separate)


3.1: what about multiple parents? I assume it's the first one, but  
should be explicit in the spec.
3.2: section is blank but contentious based on current behavior and  
the in-ability to use properties and inheritance together.
3.3: I don't understand this statement. A child always overrides  
the parent or joins with it. Are you saying that the parent wins  
here? Also pluginRepositories is going away soon. In general why  
can't the things listed here be extended?
3.4 shouldn't project.distMgt.relocation be inherited if the  
relocation lists the group? (group/artifact/version ones should be  
skipped, but if you're relocating everything in a group, it would  
make sense to do this at the top of that group tree pom)
3.5 I agree with Ralph here that Final is the wrong term. Private  
is more appropriate.


I started this in the morning and didn't finish yet so sending what  
I have.


-Original Message-
From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Sent: Tuesday,

Re: POM construction specification