Le mardi 08 avril 2008, Paul Benedict a écrit : > In Commons Validator, we updated the DTD even in point releases. I don't > see the harm in doing the same here. After all, if the POM is 4.0.0, why > not create a 4.0.1? It sounds like Maven 2 will have a 4.1 version. > > Paul because if you use 4.0.1 for your project, and upload your component to a repository, everybody depending on your component will need to support 4.0.1 or they'll get a failure parsing a 4.0.1 pom with their Maven runtime supporting only 4.0.0 pom
to support a 4.1 version, I imagine there will be some trick to implement to upload simultaneously the original 4.1 pom version to the repository and a generated 4.0.0 for compatibility with Maven 2.0.x Hervé > > On Mon, Apr 7, 2008 at 6:03 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 7-Apr-08, at 3:58 PM, Jason van Zyl wrote: > > > Would being able to detect the encoding help with making this less > > > complicated. Something JChardet? > > > > Sorry, something like JCharet: > > > > http://jchardet.sourceforge.net/ > > > > On 7-Apr-08, at 2:31 PM, Hervé BOUTEMY wrote: > > > > Le dimanche 06 avril 2008, Jason van Zyl a écrit : > > > > > I specifically meant the core changes, but I would still > > > > > recommending > > > > > what Milos did which was to create branches for a few of the > > > > > affected > > > > > plugins to try it all together. > > > > > > > > ok, I created > > > > http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/ > > > > with javadoc and jxr plugins branches to test the change, and sample > > > > use > > > > case. > > > > > > > > Most certainly to test new elements in > > > > > > > > > the POM you need to use a branch because we still don't have a > > > > > strategy for dealing with model changes. > > > > > > > > this one is more tricky, even if the change in pom.xml is a simple > > > > addition of > > > > an element... Don't really know how to handle this without breaking > > > > things > > > > for Maven 2.0 when an artifact with this addition is deployed to a > > > > repository. > > > > > > > > If plugins can be changed, used with the existing versions of Maven > > > > > > > > > with no disruption then do it in-situ. > > > > > > > > No problem here, no disruption, as proven by the test. > > > > The only risk is that the property chosen, > > > > ${project.build.sourceEncoding}, > > > > makes user think to a new element <project><build><sourceEncoding> in > > > > the > > > > pom, but we still don't know how we will implement it: we bet on a > > > > solution > > > > we don't have currently. > > > > > > > > Hervé > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Thanks, > > > > > > Jason > > > > > > ---------------------------------------------------------- > > > Jason van Zyl > > > Founder, Apache Maven > > > jason at sonatype dot com > > > ---------------------------------------------------------- > > > > > > A man enjoys his work when he understands the whole and when he > > > is responsible for the quality of the whole > > > > > > -- Christopher Alexander, A Pattern Language > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > jason at sonatype dot com > > ---------------------------------------------------------- > > > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
