Re: svn commit: r775216 - in /maven/ant-tasks/branches/maven-ant-tasks-2.0.x: pom.xml src/assembly/ src/assembly/src.xml

[Brett Porter]

On 16/05/2009, at 6:44 AM, Paul Gier wrote:



Ok, it's fixed.  Thanks for the suggestions!  Brian are the  
requirements for the  source distribution defined somewhere?  So I  
can make sure I'm not missing anything?


What you have now looks right to me.

I would personally not bother with the tar.bz2 (something I'd now say  
even for binaries) - the time it takes to build and extra upload  
doesn't seem to provide enough value.


Cheers,
Brett

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

Re: [VOTE] Java 5 and Maven Plugins

[Brett Porter]

On 16/05/2009, at 5:06 AM, Stephane Nicoll wrote:


On Fri, May 15, 2009 at 6:58 PM, Benjamin Bentmann <
benjamin.bentm...@udo.edu> wrote:


Daniel Kulp wrote:

On Fri May 15 2009 12:18:59 pm Brian Fox wrote:


I don't think we should go out of our way yet to convert  
everything to
java5, preserving 1.4 compatibility (essentially 2.0/2.1  
compatibility)
should be considered. However if there's a reason, like the  
checkstyle
update requies java 5, then we should do it and set a  
prerequisite of

maven
2.2.0.



I don't think setting a prerequisite of 2.2.0 is a good idea.   If  
the
plugin will work with 2.0.10 + java 5, then I think we should  
allow that.




I agree with Dan, the prerequisite on a specific Maven version and  
a Java

version are two different things. Users can fairly well run plugins
targetting Java 1.5 with a core targetting 1.4.



+1


+1, including Brian's original sentiment. Be conservative but not  
restrictive.


As long as it is clearly documented in the plugin release notes / site  
(and the last version to work with 1.4 should be indicated), I think  
we can live with the occasional auto-upgrade biting people using JDK  
1.4 and having to lock down a version.


In terms of Dennis' suggestions, I would say my choice is that [B] is  
best, [A] is acceptable.


Cheers,
Brett


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

Re: Progress on support for large projects

[Brian Fox]

>
>
> You have to understand that although the problem might seem trivial, fixes
> for problems like this can't break existing builds. That makes even the
> simplest fix challenging.
>

Not only that, it needs to cooperate with other functionality... just like
we found with the previous patch. It would work in some cases but it
couldn't function if the build.outputDirectory was changed. (or -f was used
for a different pom name).

Re: Progress on support for large projects

[Ralph Goers]

On May 15, 2009, at 1:10 PM, Joerg Hohwiller wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,


I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.


MNG-624 or maven-2.1.x-MNG-624 ?
I think it was maven-2.1.x-MNG-624. Its been a long time since I  
worked on this.






A big problem could be the encoding issue if you store XML in a  
string
and then want to save it with some Writer, you need to know the  
encoding

from the XML-header or you run into trouble.


My fix didn't store the XML in a string, it modified the DOM.


OK. But the existing parsing is done by XPP right?

I believe so.



Do we want parsing the POMs twice with different parsers?





Is there some general strategy decision about POM-transformation
design by the core developers of maven?
Maven 2.x is a mess with this. It is one of the things I believe they  
worked really hard to change in Maven 3. Again, I haven't reviewed the  
new code so I don't know how successful they were.



Do Brett and Jason care about this?
Everybody cares about this. The way Maven 2.x was implemented is very  
brittle. Almost every change made to the project builder ends up  
having nasty side effects.



Sorry for the stupid question, but your patch/branch seems to
be the second solution so this means to me that the first
has failed already. I now see that is was Eric Brown who
wasted his time already and he seemed somewhat disappointed.
As the problem of doing a POM-transformation
which is NOT only relevant for MNG-624 is quite general.
So I just want to avoid that the second approach will fail again.
I would not mind to invest some of my very little time as well
in this but only if there is a clear chance that we are going
towards a solution that fits well into the architecture of maven
and will therefore be accepted to be integrated in 2.1.x.


I seemed to be the only committer interested in fixing these issues. I  
did not like Eric's patch because it added logic the the artifact  
handler that it had no business knowing about.  As I recall I  
documented my reasons in one of the Jira issues.


You have to understand that although the problem might seem trivial,  
fixes for problems like this can't break existing builds. That makes  
even the simplest fix challenging.


Ralph


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

Re: svn commit: r775177 - /maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java

[Vincent Siveton]

Hi Jason,

Thanks for your log.

Yes I think your changes are corrects. Could you please merge them to
the branch too [1]?

Cheers,

Vincent

[1] 
https://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-doxia-1.1

2009/5/15  :
> Author: jvanzyl
> Date: Fri May 15 15:06:30 2009
> New Revision: 775177
>
> URL: http://svn.apache.org/viewvc?rev=775177&view=rev
> Log:
> o Dennis, Vincent and Lukas, I have removed the reference to the 
> MavenProjectBuilder here and all tests seem to pass. I am trying to reduce 
> the signature foot print of the MavenProjectBuilder and older versions of the 
> site plugin (or underlying tools like doxia) seem to use:
>
>    MavenProject build( File project, ArtifactRepository localRepository, 
> ProfileManager profileManager )
>        throws ProjectBuildingException;
>
> If I can get rid of that signature I want to because I don't want to get rid 
> of the ProfileManager from any public signatures.
>
> Could you guys verify this is ok to remove, if so then I will take this 
> method out from the public signature of the project builder.
>
>
> Modified:
>    
> maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java
>
> Modified: 
> maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java
> URL: 
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java?rev=775177&r1=775176&r2=775177&view=diff
> ==
> --- 
> maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java
>  (original)
> +++ 
> maven/plugins/trunk/maven-site-plugin/src/main/java/org/apache/maven/plugins/site/AbstractSiteMojo.java
>  Fri May 15 15:06:30 2009
> @@ -32,7 +32,6 @@
>  import org.apache.maven.doxia.tools.SiteTool;
>  import org.apache.maven.plugin.AbstractMojo;
>  import org.apache.maven.project.MavenProject;
> -import org.apache.maven.project.MavenProjectBuilder;
>  import org.apache.maven.reporting.MavenReport;
>  import org.codehaus.plexus.i18n.I18N;
>  import org.codehaus.plexus.util.ReaderFactory;
> @@ -101,13 +100,6 @@
>     protected List reactorProjects;
>
>     /**
> -     * Project builder
> -     *
> -     * @component
> -     */
> -    protected MavenProjectBuilder mavenProjectBuilder;
> -
> -    /**
>      * Specifies the input encoding.
>      *
>      * @parameter expression="${encoding}" 
> default-value="${project.build.sourceEncoding}"
>
>
>

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

Re: svn commit: r775049 - in /maven/plugins/trunk/maven-checkstyle-plugin: ./ src/main/java/org/apache/maven/plugin/checkstyle/ src/main/resources/config/ src/test/java/org/apache/maven/plugin/checkst

[Benjamin Bentmann]

Dennis Lundberg wrote:


- If I understand the new configuration for Checkstyle 5 (haven't used
it yet myself), you have changed the configuration for
HtmlPackage/JavadocPackage compared to how it used to work.


Not sure whether that's related to Dennis' remarks but it appears the 
recent changes to the plugin broke the ITs [0].



Benjamin


[0] 
https://grid.sonatype.org/ci/job/plugins-IT-with-maven-2.1.x/jdk=1.5,label=ubuntu/56/changes


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

Re: Progress on support for large projects

[Brian Fox]

>
>
> Do you need simple IT-projects that I shall attach to MNG-4161 and related?
>

Sample ITs for sure, and some level of detail in a proposal like these:
http://docs.codehaus.org/display/MAVENUSER/User+Proposals

Re: svn commit: r775216 - in /maven/ant-tasks/branches/maven-ant-tasks-2.0.x: pom.xml src/assembly/ src/assembly/src.xml

[Paul Gier]

Benjamin Bentmann wrote:

Hi Paul,


Author: pgier
Date: Fri May 15 16:16:59 2009
New Revision: 775216

URL: http://svn.apache.org/viewvc?rev=775216&view=rev
Log:
Add configuration for creating the src dist files during a realease.

Added:
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/

maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml   
(with props)

Modified:
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/pom.xml


Added: 
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml
URL: 
http://svn.apache.org/viewvc/maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml?rev=775216&view=auto 

== 

--- 
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml 
(added)
+++ 
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml 
Fri May 15 16:16:59 2009

@@ -0,0 +1,29 @@
+
+  src
+  
+tar.gz
+zip
+  
+  false
+  
+
+  ${project.basedir}
+  /
+  true
+  
+target/**
+*~
+*.log
+.classpath
+.project
+.settings/**
+*.ipr
+*.iws
+*.iml
+.wtpmodules
+target-eclipse/**
+bin/**
+  
+
+  
+


This descriptor heavily relies on exclusions for the proper contents. If 
somebody has files in the project base directory that you didn't 
anticipate, the source bundle gets spoiled. I believe using includes is 
safer and easier to maintain, i.e. include "${basedir}/src" and the few 
others files from the base directory like the predefined src descriptor 
of the Assembly Plugin does.


The resulting source bundle seems to miss LICENSE and NOTICE files.

The directory structure of source bundle does not root in a directory 
named after the bundle, i.e.


  maven-ant-tasks-2.0.10/
src/

No biggie yet something that should be synced up with the format 
required/expected by ASF. Brian is probably the best to tell what's 
required, I only noticed the bundle differs from the last source bundle 
for Maven 2.1.0-M1 [1].


Also, what archive formats are we expected to create? The predefined src 
descriptor produces zip, tar.gz and tar.bz2. In contrast the 
hand-written descriptor for the Ant Tasks misses tar.bz2.


Sorry that I can't provide answers to these by myself, just wanted to 
save you from another release that might be cancelled.



Benjamin


[0] 
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#src 


[1] http://apache.org/dist/maven/source/apache-maven-2.1.0-M1-src.zip

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



Ok, it's fixed.  Thanks for the suggestions!  Brian are the requirements for the 
 source distribution defined somewhere?  So I can make sure I'm not missing 
anything?


Thanks!

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again,


>> Your better bet will be to try and get this documented so it can be
>> implemented in 3.x.

no change to see some improvement about version maintenance in 2.x?
See the list of issues I just posted and also look at the votes.

Thanks
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoN0zkACgkQmPuec2Dcv/+QagCgiQd4XEKgBWh4c98TkflW3Bek
2GcAnRdoBJSi3wWoLHEA6jJB3N8pvSAr
=l02j
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian,

> Your better bet will be to try and get this documented so it can be
> implemented in 3.x.

I would surely NOT mind. What do you expect?
A new xdoc? Or a diff to the actual source of
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Content somewhat like the level of detail in MNG-4161
but with nice examples?

Do you need simple IT-projects that I shall attach to MNG-4161 and related?

Best regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoN0p4ACgkQmPuec2Dcv/8TnwCfRZXQ8Wz1OOMwq4B8MXKanWyo
4qUAn0vYofuQCDUjS+PjOQ46VvgfpUUN
=GiG2
-END PGP SIGNATURE-

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

Maven and maintaining

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

After I got lost in the thread "Progress on support for large projects"
and opened MNG-4161, I started to collect everything that is going on
in JIRA about this. I added this to MNG-4161 but also wanted to
point this out here:

* MNG-624 - automatic parent versioning
* MNG-2412 - global variable filtering of pom.xml for parent and
  sub module pom.xml files is not working when deploying to a repository.
* MNG-2446 - parent Pom properties not resolved for module dependencies
* MNG-2971 - Variables are not replaced into installed pom file
* MNG-3057 - properties not expanded in generated POMs when building A/B/C
nested projects
* MNG-3782 - [regression] Variable substition not performed in transitive
dependency using value from active profile
* MNG-4161 - possibility to omit version in dependency of same project (and
fill in on install/deploy)
* MARTIFACT-32 - Maven does not expand expressions while installing
artifacts locally
* MINSTALL-50 - provide property filtering on .pom files placed in local 
repo

Quite impressive list. So there seems to be a high demand in this topic.
Maybe we should bring some things together.

Take care
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoN0Z8ACgkQmPuec2Dcv/8mDwCdFy4uCjoxDVf7CWyQVhYUCeRw
xwYAnREHSE6L2ApaUVDqshHbPXO74sb6
=bDbL
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

On Fri, May 15, 2009 at 4:10 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> > I think you are referring to one of the other patches that was
> > submitted, not what I committed to the MNG-624 branch.
>
> MNG-624 or maven-2.1.x-MNG-624 ?
>
> >>
> >>
> >> A big problem could be the encoding issue if you store XML in a string
> >> and then want to save it with some Writer, you need to know the encoding
> >> from the XML-header or you run into trouble.
> >
> > My fix didn't store the XML in a string, it modified the DOM.
>
> OK. But the existing parsing is done by XPP right?
>
> Do we want parsing the POMs twice with different parsers?
>
> Is there some general strategy decision about POM-transformation
> design by the core developers of maven?
>
> Do Brett and Jason care about this?
>
> Sorry for the stupid question, but your patch/branch seems to
> be the second solution so this means to me that the first
> has failed already. I now see that is was Eric Brown who
> wasted his time already and he seemed somewhat disappointed.
> As the problem of doing a POM-transformation
> which is NOT only relevant for MNG-624 is quite general.
> So I just want to avoid that the second approach will fail again.
> I would not mind to invest some of my very little time as well
> in this but only if there is a clear chance that we are going
> towards a solution that fits well into the architecture of maven
> and will therefore be accepted to be integrated in 2.1.x.
>

Your better bet will be to try and get this documented so it can be
implemented in 3.x.

>
> >
> > Ralph
>
> Regards
>  Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66
> vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku
> =xUpi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

> I think you are referring to one of the other patches that was
> submitted, not what I committed to the MNG-624 branch.

MNG-624 or maven-2.1.x-MNG-624 ?

>>
>>
>> A big problem could be the encoding issue if you store XML in a string
>> and then want to save it with some Writer, you need to know the encoding
>> from the XML-header or you run into trouble.
> 
> My fix didn't store the XML in a string, it modified the DOM.

OK. But the existing parsing is done by XPP right?

Do we want parsing the POMs twice with different parsers?

Is there some general strategy decision about POM-transformation
design by the core developers of maven?

Do Brett and Jason care about this?

Sorry for the stupid question, but your patch/branch seems to
be the second solution so this means to me that the first
has failed already. I now see that is was Eric Brown who
wasted his time already and he seemed somewhat disappointed.
As the problem of doing a POM-transformation
which is NOT only relevant for MNG-624 is quite general.
So I just want to avoid that the second approach will fail again.
I would not mind to invest some of my very little time as well
in this but only if there is a clear chance that we are going
towards a solution that fits well into the architecture of maven
and will therefore be accepted to be integrated in 2.1.x.

> 
> Ralph

Regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66
vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku
=xUpi
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> 
> Off topic.
> 
> Actually I believe this isn't true anymore.
> 
> See http://jira.codehaus.org/browse/MECLIPSE-344
> "all dependent artefacts that are available in your eclipse-workspace
> will be attached as project references even if they are not in the
> reactor."
> It was fixed in 2.5
> 
> Can you try it on your project structure and confirm?
> 
> I know it works for me.
> 
> I have this structure
> 
> common projects
> - module cA
> ...
> - module cZ
> 
> My project
> - module pA
> ...
> - module pZ
> (where some of these projects depend upon projects from commons)
> 
> mvn eclipse:eclipse will make sure my module pA references the eclipse
> project for module cA (and not the jar of cA in the repo)

Thanks for the hint!
But only works if eclipse-plugin knows where my workspace is.
The location may be different for each developer so I can NOT
truly automate. Anyhow I will start using this.
At least better solution than what I had before.

Thanks
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNxrQACgkQmPuec2Dcv/8VrQCdGu/eWpZnifkPYdW/u+6RqsKx
+eMAnRv5/EHXo0895onKGsmExxxtoC70
=gj/Z
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Stephen,

> 
> If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been
> released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT)
> which is subject to change... which means that a released pom does not have
> a definitive content... bad karma

I agree and cant speak for Ralph, but I do NOT change versions (or anything
else that is relevant for deploying) of container-modules at all.
Why should I release a new version of my parent POMs if just some leave changed
or even if some internal site-report-setting changed. People that want to
use my deployed artifacts do NOT care about such changes. But in my case
every developer always checks out the entire head (or tag/branch) of SCM.
So there are different aspects of a deployed POM. If you ask me, all stuff
like , , , , etc.
is nuts for deployed POMs. But others may have a different view of the world.

But this might be the point where we do not get together with relase-plugin.
We simply have to accept that maven gives us flexibility to do things different
ways and release-plugin maybe can NOT address all of these ways and thats
just OK.

> 
> -Stephen
> 

Regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNxdIACgkQmPuec2Dcv/8SEgCgl/9Hnv5vfFAaRpz3noNdZuW1
x/IAn0AOXx3MSnC9xWvWFZKrZURU7OcR
=aIQF
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Brian Fox]

On Fri, May 15, 2009 at 2:58 PM, Joerg Hohwiller wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
>
> > By inheriting the version, groupId, etc. from the parent - yes. The
> > release plugin still handles the pom transformations and the tagging
> > (SCM URLs, snapshot to release version, release to next snapshot
> > version, etc.)
>
> But there is nothing to change in the POM if the version is a variable.
> Maven will (as suggested in this thread - or also in my usecase via
> xslt-plugin) replace the variable when installing. All I need to change
> is one variable (e.g. in settings.xml). I do not need a releas-plugin
> for that but others may want to.
>
> >
> >  I am also doing this in some other project that way and
> >> it works fine. But in my personal open-source project I have some
> >> core-libs that are used throughout the project and many modules that
> >> are piled up with lots of dependencies. I have some modules that
> >> are quite steady and do not change so I dont want to release a new
> >> version just because something else changed.
> >
> > I would try splitting those steady modules from the rest of the
> > structure since they seem to not share a common development/release
> > cycle. I would even consider moving these to another svn repository.
> > Without a real example to analyze, hard to tell.
>
> Once again: the release-plugin guys think in a specific way and there
> are others that have a different oppinion. For me the architecture
> of the system is the main criteria for structuring my pom-tree.
> Imagine that everybody makes it the way you describe because of
> release-plugin. The other day another cool plugin arises that forces
> you to structure your poms and scm by some other criteria.
> What if you want both plugins?
>

I wouldn't say it's the release plugin that dictates the layout, its what
makes sense in the scm. Generally you take a tree of things and tag it and
release it.


>
> I think it is a bad idea that a plugin gives a philosophy about
> how users should structure their project.
>
> Regards
>  Jörg
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6
> pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F
> =HnyW
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Java 5 and Maven Plugins

[Stephane Nicoll]

On Fri, May 15, 2009 at 6:58 PM, Benjamin Bentmann <
benjamin.bentm...@udo.edu> wrote:

> Daniel Kulp wrote:
>
>  On Fri May 15 2009 12:18:59 pm Brian Fox wrote:
>>
>>> I don't think we should go out of our way yet to convert everything to
>>> java5, preserving 1.4 compatibility (essentially 2.0/2.1 compatibility)
>>> should be considered. However if there's a reason, like the checkstyle
>>> update requies java 5, then we should do it and set a prerequisite of
>>> maven
>>> 2.2.0.
>>>
>>
>> I don't think setting a prerequisite of 2.2.0 is a good idea.   If the
>> plugin will work with 2.0.10 + java 5, then I think we should allow that.
>>
>
> I agree with Dan, the prerequisite on a specific Maven version and a Java
> version are two different things. Users can fairly well run plugins
> targetting Java 1.5 with a core targetting 1.4.


+1

Stéphane

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


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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,


> By inheriting the version, groupId, etc. from the parent - yes. The
> release plugin still handles the pom transformations and the tagging
> (SCM URLs, snapshot to release version, release to next snapshot
> version, etc.)

But there is nothing to change in the POM if the version is a variable.
Maven will (as suggested in this thread - or also in my usecase via
xslt-plugin) replace the variable when installing. All I need to change
is one variable (e.g. in settings.xml). I do not need a releas-plugin
for that but others may want to.

> 
>  I am also doing this in some other project that way and
>> it works fine. But in my personal open-source project I have some
>> core-libs that are used throughout the project and many modules that
>> are piled up with lots of dependencies. I have some modules that
>> are quite steady and do not change so I dont want to release a new
>> version just because something else changed.
> 
> I would try splitting those steady modules from the rest of the
> structure since they seem to not share a common development/release
> cycle. I would even consider moving these to another svn repository.
> Without a real example to analyze, hard to tell.

Once again: the release-plugin guys think in a specific way and there
are others that have a different oppinion. For me the architecture
of the system is the main criteria for structuring my pom-tree.
Imagine that everybody makes it the way you describe because of
release-plugin. The other day another cool plugin arises that forces
you to structure your poms and scm by some other criteria.
What if you want both plugins?

I think it is a bad idea that a plugin gives a philosophy about
how users should structure their project.

Regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6
pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F
=HnyW
-END PGP SIGNATURE-

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

Re: Progress on support for large projects

[Joerg Hohwiller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi there,

>>
>> OK. So you would NOT mind if maven adds some new features that
>> are compatible to older versions of maven.
>> Thats all I am fighting for.
>>
> 
> No fighting required, just make a patch. If it's truly backwards compatible,
> then there wouldn't be much reason for it to be declined.
> 
> I'm interested in the use cases because during training I run into this a
> lot. Generally if you can move your process to one that works with Maven
> then it's not an issue. If you can't, well then it is. I've got ideas for
> how to make the release process better, but not enough time to tackle it
> now. Just updating the tools to support ASF policy is keeping me busy
> enough.
> 

I searched JIRA:
It was already requested in MNG-2576 so it seems the idea and usecase
is common and therefor good. The issue is closed/fixed but I could NOT
get it working...

Regards
  Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoNub8ACgkQmPuec2Dcv//RVQCgiqgQEvovdbDo+LHWBxbzOebn
jUYAn0d4lIFFM1dTNa7A3dWeC1Q+OsgD
=9QN4
-END PGP SIGNATURE-

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

Re: svn commit: r774925 - /maven/components/branches/MNG-2766/maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java

[Benjamin Bentmann]

Jason van Zyl wrote:

Can we move this out of here and do in some other part of the 
configuration processing?


I will investigate. The challenge is that we definitively want 
expressions in the plugin configuration to be evaluated lately and say 
not during the initial model construction because otherwise expressions 
like "${project.compileSourceRoots}" would miss generated stuff. Maybe 
we could just make Plexus use a Maven-specific FileConverter instead 
baking in the basedir alignment into the default FileConverter.



Benjamin

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

Re: svn commit: r775216 - in /maven/ant-tasks/branches/maven-ant-tasks-2.0.x: pom.xml src/assembly/ src/assembly/src.xml

[Benjamin Bentmann]

Hi Paul,


Author: pgier
Date: Fri May 15 16:16:59 2009
New Revision: 775216

URL: http://svn.apache.org/viewvc?rev=775216&view=rev
Log:
Add configuration for creating the src dist files during a realease.

Added:
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml   (with 
props)
Modified:
maven/ant-tasks/branches/maven-ant-tasks-2.0.x/pom.xml


Added: maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml
URL: 
http://svn.apache.org/viewvc/maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml?rev=775216&view=auto
==
--- maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml (added)
+++ maven/ant-tasks/branches/maven-ant-tasks-2.0.x/src/assembly/src.xml Fri May 
15 16:16:59 2009
@@ -0,0 +1,29 @@
+
+  src
+  
+tar.gz
+zip
+  
+  false
+  
+
+  ${project.basedir}
+  /
+  true
+  
+target/**
+*~
+*.log
+.classpath
+.project
+.settings/**
+*.ipr
+*.iws
+*.iml
+.wtpmodules
+target-eclipse/**
+bin/**
+  
+
+  
+


This descriptor heavily relies on exclusions for the proper contents. If 
somebody has files in the project base directory that you didn't 
anticipate, the source bundle gets spoiled. I believe using includes is 
safer and easier to maintain, i.e. include "${basedir}/src" and the few 
others files from the base directory like the predefined src descriptor 
of the Assembly Plugin does.


The resulting source bundle seems to miss LICENSE and NOTICE files.

The directory structure of source bundle does not root in a directory 
named after the bundle, i.e.


  maven-ant-tasks-2.0.10/
src/

No biggie yet something that should be synced up with the format 
required/expected by ASF. Brian is probably the best to tell what's 
required, I only noticed the bundle differs from the last source bundle 
for Maven 2.1.0-M1 [1].


Also, what archive formats are we expected to create? The predefined src 
descriptor produces zip, tar.gz and tar.bz2. In contrast the 
hand-written descriptor for the Ant Tasks misses tar.bz2.


Sorry that I can't provide answers to these by myself, just wanted to 
save you from another release that might be cancelled.



Benjamin


[0] 
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#src

[1] http://apache.org/dist/maven/source/apache-maven-2.1.0-M1-src.zip

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

Re: [VOTE] Java 5 and Maven Plugins

[Benjamin Bentmann]

Daniel Kulp wrote:


On Fri May 15 2009 12:18:59 pm Brian Fox wrote:

I don't think we should go out of our way yet to convert everything to
java5, preserving 1.4 compatibility (essentially 2.0/2.1 compatibility)
should be considered. However if there's a reason, like the checkstyle
update requies java 5, then we should do it and set a prerequisite of maven
2.2.0.


I don't think setting a prerequisite of 2.2.0 is a good idea.   If the plugin 
will work with 2.0.10 + java 5, then I think we should allow that.


I agree with Dan, the prerequisite on a specific Maven version and a 
Java version are two different things. Users can fairly well run plugins 
targetting Java 1.5 with a core targetting 1.4.



Benjamin

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

Re: [VOTE] Java 5 and Maven Plugins

[Daniel Kulp]

On Fri May 15 2009 12:18:59 pm Brian Fox wrote:
> I don't think we should go out of our way yet to convert everything to
> java5, preserving 1.4 compatibility (essentially 2.0/2.1 compatibility)
> should be considered. However if there's a reason, like the checkstyle
> update requies java 5, then we should do it and set a prerequisite of maven
> 2.2.0.

I don't think setting a prerequisite of 2.2.0 is a good idea.   If the plugin 
will work with 2.0.10 + java 5, then I think we should allow that.   I DON'T 
see many people moving to maven 2.2.x for a while. 

Dan


> On Fri, May 15, 2009 at 11:05 AM, nicolas de loof
>
> wrote:
> > I myself have been very conservative about Java updates because I still
> > have
> > to support Java 1.3 applications. I learned to use Maven with JDK6 and
> > target 1.3 environment.
> > for this reason I'm +1 with [A] or [B] (depending on the status of
> > SNAPSHOT plugins that in some cas include major fix compared to latest
> > release) Nicolas
> >
> > 2009/5/15 Dennis Lundberg 
> >
> > > Hi
> > >
> > > Recent discussions about the Checkstyle Plugin has raised the question
> > > of requiring Java 5 in Maven Plugins.
> > >
> > > We will IIUC require Java 5 for Maven 2.2. So when do we start using it
> > > in our plugins?
> > >
> > > [A] We start using it across the board for the next release of every
> > > plugin that wants to use Java 5 features or needs a dependency that
> > > requires Java 5.
> > >
> > > [B] The plugins can start using Java 5 features and/or dependencies. It
> > > is required that the current trunk of the plugin is released first,
> > > targeting Java 1.4. In the announcement for that last Java 1.4 version
> > > of the plugin, we inform the users that this is the last version that
> > > will be able to run on Java 1.4.
> > >
> > > [C] The plugins should not use Java 5 features. We can use
> > > retrotranslator, or something similar, to handle dependencies that
> > > require Java 5.
> > >
> > > [D] The plugins should not use Java 5 features. We will not update
> > > dependencies unless a "-java14" classified artifact is readily
> > > available from the developers of any dependencies.
> > >
> > >
> > > If you feel that there are other options we can take, please feel free
> > > to put them into the mix.
> > >
> > > --
> > > Dennis Lundberg
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org

-- 
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog

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

Re: [VOTE] Java 5 and Maven Plugins

[Brian Fox]

I don't think we should go out of our way yet to convert everything to
java5, preserving 1.4 compatibility (essentially 2.0/2.1 compatibility)
should be considered. However if there's a reason, like the checkstyle
update requies java 5, then we should do it and set a prerequisite of maven
2.2.0.

On Fri, May 15, 2009 at 11:05 AM, nicolas de loof
wrote:

> I myself have been very conservative about Java updates because I still
> have
> to support Java 1.3 applications. I learned to use Maven with JDK6 and
> target 1.3 environment.
> for this reason I'm +1 with [A] or [B] (depending on the status of SNAPSHOT
> plugins that in some cas include major fix compared to latest release)
> Nicolas
>
> 2009/5/15 Dennis Lundberg 
>
> > Hi
> >
> > Recent discussions about the Checkstyle Plugin has raised the question
> > of requiring Java 5 in Maven Plugins.
> >
> > We will IIUC require Java 5 for Maven 2.2. So when do we start using it
> > in our plugins?
> >
> > [A] We start using it across the board for the next release of every
> > plugin that wants to use Java 5 features or needs a dependency that
> > requires Java 5.
> >
> > [B] The plugins can start using Java 5 features and/or dependencies. It
> > is required that the current trunk of the plugin is released first,
> > targeting Java 1.4. In the announcement for that last Java 1.4 version
> > of the plugin, we inform the users that this is the last version that
> > will be able to run on Java 1.4.
> >
> > [C] The plugins should not use Java 5 features. We can use
> > retrotranslator, or something similar, to handle dependencies that
> > require Java 5.
> >
> > [D] The plugins should not use Java 5 features. We will not update
> > dependencies unless a "-java14" classified artifact is readily available
> > from the developers of any dependencies.
> >
> >
> > If you feel that there are other options we can take, please feel free
> > to put them into the mix.
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: svn commit: r775049 - in /maven/plugins/trunk/maven-checkstyle-plugin: ./ src/main/java/org/apache/maven/plugin/checkstyle/ src/main/resources/config/ src/test/java/org/apache/maven/plugin/checkst

[Dennis Lundberg]

A couple of things that caught my attention in this commit. First some
general ones:

- Please commit each issue by itself, as it makes rolling back stuff
much easier.

- If you can, please try to to code beautifications in separate commits
if possible. It tends to distract from the real issue that is being
solved. Stuff like optimize imports and such.


And now some specific things about the issues that was solved by this
commit:

- We should discuss whether to use Java 5 or not, before we commit a fix
for MCHECKSTYLE-105. See my comments in that issue and on the dev list

- If I understand the new configuration for Checkstyle 5 (haven't used
it yet myself), you have changed the configuration for
HtmlPackage/JavadocPackage compared to how it used to work. IIUC
package.html files are no longer allowed in the configurations for
Avalon, Maven and Turbine. If we want to change that it's better to open
a separate issue for that, and commit that separately. I don't think we
should change the behavior, so I am -1 to the change in configuration. I
believe we should have the config below to have the plugin work the same
way as before:


  


- The ASF license header in
maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/sun_checks.xml
was lost in this commit. Was that intentional?


nico...@apache.org wrote:
> Author: nicolas
> Date: Fri May 15 07:36:54 2009
> New Revision: 775049
> 
> URL: http://svn.apache.org/viewvc?rev=775049&view=rev
> Log:
> MCHECKSTYLE-105 + MCHECKSTYLE-101
> 
> Modified:
> maven/plugins/trunk/maven-checkstyle-plugin/pom.xml
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReportGenerator.java
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/avalon_checks.xml
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/maven_checks.xml
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/sun_checks.xml
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/config/turbine_checks.xml
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/test/java/org/apache/maven/plugin/checkstyle/CheckstyleReportListenerTest.java
> 
> maven/plugins/trunk/maven-checkstyle-plugin/src/test/java/org/apache/maven/plugin/checkstyle/CheckstyleResultsTest.java
> 
> Modified: maven/plugins/trunk/maven-checkstyle-plugin/pom.xml
> URL: 
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-checkstyle-plugin/pom.xml?rev=775049&r1=775048&r2=775049&view=diff
> ==
> --- maven/plugins/trunk/maven-checkstyle-plugin/pom.xml (original)
> +++ maven/plugins/trunk/maven-checkstyle-plugin/pom.xml Fri May 15 07:36:54 
> 2009
> @@ -127,12 +127,7 @@
>  
>checkstyle
>checkstyle
> -  4.4
> -
> -
> -  checkstyle
> -  checkstyle-optional
> -  4.4
> +  5.0
>  
>  
>org.apache.maven.shared
> 
> Modified: 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
> URL: 
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java?rev=775049&r1=775048&r2=775049&view=diff
> ==
> --- 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
>  (original)
> +++ 
> maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/CheckstyleReport.java
>  Fri May 15 07:36:54 2009
> @@ -19,20 +19,27 @@
>   * under the License.
>   */
>  
> -import com.puppycrawl.tools.checkstyle.Checker;
> -import com.puppycrawl.tools.checkstyle.ConfigurationLoader;
> -import com.puppycrawl.tools.checkstyle.DefaultConfiguration;
> -import com.puppycrawl.tools.checkstyle.DefaultLogger;
> -import com.puppycrawl.tools.checkstyle.ModuleFactory;
> -import com.puppycrawl.tools.checkstyle.PackageNamesLoader;
> -import com.puppycrawl.tools.checkstyle.PropertiesExpander;
> -import com.puppycrawl.tools.checkstyle.XMLLogger;
> -import com.puppycrawl.tools.checkstyle.api.AuditListener;
> -import com.puppycrawl.tools.checkstyle.api.CheckstyleException;
> -import com.puppycrawl.tools.checkstyle.api.Configuration;
> -import com.puppycrawl.tools.checkstyle.api.FilterSet;
> -import com.puppycrawl.tools.checkstyle.api.SeverityLevel;
> -import com.puppycrawl.tools.checkstyle.filters.SuppressionsLoader;
> +import java.io.ByteArrayOutputStream;
> +import java.io.File;
> +import java.io.FileInputStream;
> +import java.io.FileNotFoundException;
> +import java.io.FileOutputStream;
> +import java.io.IOException;
> +import java.io.Out

Re: [VOTE] Java 5 and Maven Plugins

[nicolas de loof]

I myself have been very conservative about Java updates because I still have
to support Java 1.3 applications. I learned to use Maven with JDK6 and
target 1.3 environment.
for this reason I'm +1 with [A] or [B] (depending on the status of SNAPSHOT
plugins that in some cas include major fix compared to latest release)
Nicolas

2009/5/15 Dennis Lundberg 

> Hi
>
> Recent discussions about the Checkstyle Plugin has raised the question
> of requiring Java 5 in Maven Plugins.
>
> We will IIUC require Java 5 for Maven 2.2. So when do we start using it
> in our plugins?
>
> [A] We start using it across the board for the next release of every
> plugin that wants to use Java 5 features or needs a dependency that
> requires Java 5.
>
> [B] The plugins can start using Java 5 features and/or dependencies. It
> is required that the current trunk of the plugin is released first,
> targeting Java 1.4. In the announcement for that last Java 1.4 version
> of the plugin, we inform the users that this is the last version that
> will be able to run on Java 1.4.
>
> [C] The plugins should not use Java 5 features. We can use
> retrotranslator, or something similar, to handle dependencies that
> require Java 5.
>
> [D] The plugins should not use Java 5 features. We will not update
> dependencies unless a "-java14" classified artifact is readily available
> from the developers of any dependencies.
>
>
> If you feel that there are other options we can take, please feel free
> to put them into the mix.
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Java 5 and Maven Plugins

[Dennis Lundberg]

Hi

Recent discussions about the Checkstyle Plugin has raised the question
of requiring Java 5 in Maven Plugins.

We will IIUC require Java 5 for Maven 2.2. So when do we start using it
in our plugins?

[A] We start using it across the board for the next release of every
plugin that wants to use Java 5 features or needs a dependency that
requires Java 5.

[B] The plugins can start using Java 5 features and/or dependencies. It
is required that the current trunk of the plugin is released first,
targeting Java 1.4. In the announcement for that last Java 1.4 version
of the plugin, we inform the users that this is the last version that
will be able to run on Java 1.4.

[C] The plugins should not use Java 5 features. We can use
retrotranslator, or something similar, to handle dependencies that
require Java 5.

[D] The plugins should not use Java 5 features. We will not update
dependencies unless a "-java14" classified artifact is readily available
from the developers of any dependencies.


If you feel that there are other options we can take, please feel free
to put them into the mix.

-- 
Dennis Lundberg

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

Re: Checkstyle plugin - upgrade to checkstyle 5 ?

[Dennis Lundberg]

We should have a policy discussion about the use of Java 5 in our
plugins. I will start another thread for that.

Your question here about the Checkstyle Plugin depends on the outcome of
the policy discussion.

nicolas de loof wrote:
> Hi
> You may have noticed discussion on user list about checkstyle plugin to
> upgrade to checkstyle 5.
> (http://jira.codehaus.org/browse/MCHECKSTYLE-105)
> 
> Such upgrade would require Java5 as plugin runtime.
> What's the best option here ?
> 
> - upgrade maven-checstyle-plugin to checkstyle 5 in 2.3
> - release 2.3 with few changes from 2.2 (june 2008) and upgrade to
> checkstyle 5 for 2.4 (or 3.0) branch
> 
> I can't see a significant change since 2.2 release (see following log). For
> this reason I'd like to apply MCHECKSTYLE-105
> to
> trunk.
> 
> What's your opinion ?
> 
> Nicolas
> 
> 
> Here is the commit log for the plugin since 2.2 release :
> 
> Revision: 680642
> Author: bentmann
> Date: 09:54:33, mardi 29 juillet 2008
> Message:
> o Excluded some more not so magic numbers
> 
> 
> Revision: 682367
> Author: aheritier
> Date: 14:47:41, lundi 4 août 2008
> Message:
> Try to use the 12-SNAPSHOT parent
> 
> 
> Revision: 683667
> Author: bentmann
> Date: 20:08:15, jeudi 7 août 2008
> Message:
> o Added stub IT profile to highlight plugins during CI
> 
> 
> Revision: 684868
> Author: bentmann
> Date: 20:43:53, lundi 11 août 2008
> Message:
> o Reordered POM
> 
> 
> Revision: 684869
> Author: bentmann
> Date: 20:45:29, lundi 11 août 2008
> Message:
> o Added project description
> 
> 
> Revision: 684879
> Author: bentmann
> Date: 21:06:46, lundi 11 août 2008
> Message:
> o Added some integration tests
> 
> 
> Revision: 686066
> Author: bentmann
> Date: 00:21:48, vendredi 15 août 2008
> Message:
> o Added ASF snapshot repo to user settings of ITs (e.g. to make sure they
> can resolve snapshot parents)
> 
> 
> Revision: 689012
> Author: bentmann
> Date: 11:57:03, mardi 26 août 2008
> Message:
> o Updated index page of plugin site
> 
> 
> Revision: 689057
> Author: bentmann
> Date: 15:01:43, mardi 26 août 2008
> Message:
> o Unified plugin name
> 
> 
> Revision: 689071
> Author: bentmann
> Date: 15:36:10, mardi 26 août 2008
> Message:
> o Changed encoding of site descriptor to UTF-8 just like used for POMs
> o Updated/added license headers
> 
> 
> Revision: 689890
> Author: bentmann
> Date: 18:56:51, jeudi 28 août 2008
> Message:
> o Explicitly stated UTF-8 as file encoding
> o Updated license header
> 
> 
> Revision: 690250
> Author: bentmann
> Date: 15:27:05, vendredi 29 août 2008
> Message:
> o Updated index page of plugin site
> 
> 
> Revision: 697604
> Author: bentmann
> Date: 22:41:41, dimanche 21 septembre 2008
> Message:
> o Inherited from maven-plugins:12
> 
> 
> Revision: 697617
> Author: bentmann
> Date: 23:30:37, dimanche 21 septembre 2008
> Message:
> o Formatted/reordered POM
> 
> 
> Revision: 697620
> Author: bentmann
> Date: 23:32:44, dimanche 21 septembre 2008
> Message:
> o Removed inherited stuff
> 
> 
> Revision: 703806
> Author: hboutemy
> Date: 14:19:23, dimanche 12 octobre 2008
> Message:
> avoid warnings during unit-tests because encoding parameter not set
> 
> 
> Revision: 712554
> Author: hboutemy
> Date: 22:08:42, dimanche 9 novembre 2008
> Message:
> upgrade plexus-utils to 1.5.6
> 
> 
> Revision: 728331
> Author: bentmann
> Date: 19:48:54, samedi 20 décembre 2008
> Message:
> o Updated all plugins to use maven-invoker-plugin:1.3 to workaround MNG-3284
> and bogus CI failures
> 
> 
> Revision: 728432
> Author: bentmann
> Date: 13:29:50, dimanche 21 décembre 2008
> Message:
> o Adjusted IT settings to compensate for the unusual unix-style local repo
> path used on the Windows nodes of the Hudson grid
> 
> 
> 
> Revision: 728546
> Author: bentmann
> Date: 23:56:51, dimanche 21 décembre 2008
> Message:
> o Fixed svn:keywords
> 
> 
> Revision: 731252
> Author: bentmann
> Date: 14:11:57, dimanche 4 janvier 2009
> Message:
> o Avoided deprecated syntax @parameter expression="${component...}"
> 
> 
> Revision: 745196
> Author: brianf
> Date: 20:16:04, mardi 17 février 2009
> Message:
> use the latest parents
> 
> 
> Revision: 746480
> Author: bentmann
> Date: 11:24:49, samedi 21 février 2009
> Message:
> o Inherited from maven-plugins:13
> 
> 
> Revision: 751080
> Author: hboutemy
> Date: 22:36:09, vendredi 6 mars 2009
> Message:
> used http://maven.apache.org/xsd/* for schema location
> 
> 


-- 
Dennis Lundberg

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

AW: problems setting up maven scm

[Mark Struberg]

thomas, checkout the whole maven-scm project and do a mvn clean install from 
the top

btw, we should move this discussion over to the general dev list, since scm-dev 
will be dropped soon.

LieGrue,
strub



- Ursprüngliche Mail 
> Von: Thomas Schüttel 
> An: scm-...@maven.apache.org
> Gesendet: Freitag, den 15. Mai 2009, 11:39:18 Uhr
> Betreff: problems setting up maven scm
> 
> Hi,
> 
> I am new to Maven SCM and I am trying to setup the project in Eclipse using 
> the 
> m2eclipse plugin. Everything downloaded fine and I have now about 30 projects 
> in 
> Eclipse.
> But some projects do not compile successfully due to missing classes.
> 
> e.g. class org.apache.maven.scm.provider.cvslib.command.CvsCommandUtils does 
> not 
> compile because it cannot find 
> org.apache.maven.scm.providers.cvslib.settings.Settings.
> The class is contained in the binary distribution but apparently not in the 
> source repository. There are more classes like this one which do not seem to 
> be 
> in the source repository.
> 
> Where is the source for those files located? Or am I missing something?
> Thanks.
> 
> Tom
> __
> GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://movieflat.web.de





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

Re: Progress on support for large projects

[Christian Schulte]

Ralph Goers schrieb:
>> They just shouldn't change things significantly without good  
>> arguments.
> 
> Which are only the ones you agree with?

I am really just trying to warn you about doing something dangerous.
Mixing release versions with snapshot versions. The release plugin takes
care of this - validation rules you want to bypass for whatever reason
you may have.

-- 
Christian


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