[fluido-skin] next fluido release roadmap - suggestions required
Hi all guys, looks like Twitter's folks released the v2.0 of Bootstrap, I would suggest to copy the current fluido trunk in a 1_X branch, and moving the fluido development to 2.0 version, upgrading Bootstrap. WDYT? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [fluido-skin] next fluido release roadmap - suggestions required
Hello, +1 2012/2/1 Simone Tripodi simonetrip...@apache.org: Hi all guys, looks like Twitter's folks released the v2.0 of Bootstrap, I would suggest to copy the current fluido trunk in a 1_X branch, and moving the fluido development to 2.0 version, upgrading Bootstrap. WDYT? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [fluido-skin] next fluido release roadmap - suggestions required
+1 Emmanuel On Wed, Feb 1, 2012 at 9:08 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all guys, looks like Twitter's folks released the v2.0 of Bootstrap, I would suggest to copy the current fluido trunk in a 1_X branch, and moving the fluido development to 2.0 version, upgrading Bootstrap. WDYT? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: M3 regression: Unreliable results, because reactor fails to calculate proper build order
Jörg, I took a look in the tarball and there's no test case per se. I'll take a look this weekend and put it into the form of a standard integration test. If you can put it into the form of a standard integration test that will likely help me get further on the weekend. On Jan 31, 2012, at 11:21 PM, Jörg Schaible wrote: mjsell wrote: I too have run into this issue, but didn't have a chance to write a bug report about it. Do you know if a jira issue already exists for it? As already written: MNG-5207 - Jörg - 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 http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
[RESULT][VOTE] Release Maven Archiver 2.5, Maven Jar Plugin 2.4, Maven War Plugin 2.2 and Maven Assembly Plugin 2.3, Take2
Hi, The vote has passed with the following result : +1 (binding): Olivier, Stephane, Stephen, John, Kristian I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT][VOTE] Release Maven Surefire Plugin version 2.12, Take 2
Hi, The vote has passed with the following result : +1 (binding): Casey, Lamy, Connolly, Rosenvold I will promote the artifacts to the central repo. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven PMD Plugin version 2.7
Hi, We solved 8 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11140styleName=Htmlversion=18069 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11140status=1 Staging repo: https://repository.apache.org/content/repositories/maven-172/ Staging site: http://maven.apache.org/plugins/maven-pmd-plugin-2.7/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
AbstractRewritePomsPhase.transformProject XML-parser
Hi
while trying to resolve some MRELEASE issues until I hit the
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(MavenProject,
ReleaseDescriptor, ReleaseEnvironment, ListMavenProject, boolean,
ReleaseResult), see below.
It kind of scared me. Shouldn't there be a better solution by now, a
better XML-parser/transformer to solve this? Anyone any suggestion?
Does anyone know if this part of the code is covered enough in order to
give it a try to replace it?
I'm pretty sure that a solid implementation could solve several issues.
-Robert
private void transformProject( MavenProject project, ReleaseDescriptor
releaseDescriptor,
ReleaseEnvironment releaseEnvironment,
ListMavenProject reactorProjects,
boolean simulate, ReleaseResult result )
throws ReleaseExecutionException, ReleaseFailureException
{
Document document;
String intro = null;
String outtro = null;
try
{
String content = ReleaseUtil.readXmlFile(
ReleaseUtil.getStandardPom( project ), ls );
// we need to eliminate any extra whitespace inside elements,
as JDOM will nuke it
content = content.replaceAll( ([^!][^]*?)\\s{2,}([^]*?),
$1 $2 );
content = content.replaceAll( (\\s{2,}|[^\\s])/, $1 / );
SAXBuilder builder = new SAXBuilder();
document = builder.build( new StringReader( content ) );
// Normalize line endings to platform's style (XML processors
like JDOM normalize line endings to \n as
// per section 2.11 of the XML spec)
normaliseLineEndings( document );
// rewrite DOM as a string to find differences, since text
outside the root element is not tracked
StringWriter w = new StringWriter();
Format format = Format.getRawFormat();
format.setLineSeparator( ls );
XMLOutputter out = new XMLOutputter( format );
out.output( document.getRootElement(), w );
int index = content.indexOf( w.toString() );
if ( index = 0 )
{
intro = content.substring( 0, index );
outtro = content.substring( index + w.toString().length()
);
}
else
{
/*
* NOTE: Due to whitespace, attribute reordering or entity
expansion the above indexOf test can easily
* fail. So let's try harder. Maybe some day, when JDOM
offers a StaxBuilder and this builder employes
* XMLInputFactory2.P_REPORT_PROLOG_WHITESPACE, this whole
mess can be avoided.
*/
final String SPACE = \\s++;
final String XML =
\\?(?:(?:[^\']++)|(?:\[^\]*+\)|(?:'[^\']*+'))*+;
final String INTSUB =
\\[(?:(?:[^\'\\]]++)|(?:\[^\]*+\)|(?:'[^\']*+'))*+\\];
final String DOCTYPE =
!DOCTYPE(?:(?:[^\'\\[]++)|(?:\[^\]*+\)|(?:'[^\']*+')|(?:
+ INTSUB + ))*+;
final String PI = XML;
final String COMMENT = !--(?:[^-]|(?:-[^-]))*+--;
final String INTRO =
(?:(?: + SPACE + )|(?: + XML + )|(?: + DOCTYPE +
)|(?: + COMMENT + )|(?: + PI + ))*;
final String OUTRO = (?:(?: + SPACE + )|(?: + COMMENT
+ )|(?: + PI + ))*;
final String POM = (?s)( + INTRO + )(.*?)( + OUTRO +
);
Matcher matcher = Pattern.compile( POM ).matcher( content
);
if ( matcher.matches() )
{
intro = matcher.group( 1 );
outtro = matcher.group( matcher.groupCount() );
}
}
}
catch ( JDOMException e )
{
throw new ReleaseExecutionException( Error reading POM: +
e.getMessage(), e );
}
catch ( IOException e )
{
throw new ReleaseExecutionException( Error reading POM: +
e.getMessage(), e );
}
ScmRepository scmRepository;
ScmProvider provider;
try
{
scmRepository =
scmRepositoryConfigurator.getConfiguredRepository( releaseDescriptor,
releaseEnvironment.getSettings()
);
provider = scmRepositoryConfigurator.getRepositoryProvider(
scmRepository );
}
catch ( ScmRepositoryException e )
{
throw new ReleaseScmRepositoryException( e.getMessage(),
e.getValidationMessages() );
}
catch ( NoSuchScmProviderException e )
{
throw new ReleaseExecutionException( Unable to configure SCM
repository: + e.getMessage(), e );
}
transformDocument( project, document.getRootElement(),
releaseDescriptor, reactorProjects,
Re: AbstractRewritePomsPhase.transformProject XML-parser
Some of the pom rewriting tricks I use in v-m-p might help... but
ultimately I think the solution lies with something like
xevpp.codehaus.org (if I ever get time to finish that :rolleyes: :-) )
On 1 February 2012 21:33, Robert Scholte apa...@sourcegrounds.com wrote:
Hi
while trying to resolve some MRELEASE issues until I hit the
org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(MavenProject,
ReleaseDescriptor, ReleaseEnvironment, ListMavenProject, boolean,
ReleaseResult), see below.
It kind of scared me. Shouldn't there be a better solution by now, a better
XML-parser/transformer to solve this? Anyone any suggestion?
Does anyone know if this part of the code is covered enough in order to give
it a try to replace it?
I'm pretty sure that a solid implementation could solve several issues.
-Robert
private void transformProject( MavenProject project, ReleaseDescriptor
releaseDescriptor,
ReleaseEnvironment releaseEnvironment,
ListMavenProject reactorProjects,
boolean simulate, ReleaseResult result )
throws ReleaseExecutionException, ReleaseFailureException
{
Document document;
String intro = null;
String outtro = null;
try
{
String content = ReleaseUtil.readXmlFile(
ReleaseUtil.getStandardPom( project ), ls );
// we need to eliminate any extra whitespace inside elements, as
JDOM will nuke it
content = content.replaceAll( ([^!][^]*?)\\s{2,}([^]*?),
$1 $2 );
content = content.replaceAll( (\\s{2,}|[^\\s])/, $1 / );
SAXBuilder builder = new SAXBuilder();
document = builder.build( new StringReader( content ) );
// Normalize line endings to platform's style (XML processors
like JDOM normalize line endings to \n as
// per section 2.11 of the XML spec)
normaliseLineEndings( document );
// rewrite DOM as a string to find differences, since text
outside the root element is not tracked
StringWriter w = new StringWriter();
Format format = Format.getRawFormat();
format.setLineSeparator( ls );
XMLOutputter out = new XMLOutputter( format );
out.output( document.getRootElement(), w );
int index = content.indexOf( w.toString() );
if ( index = 0 )
{
intro = content.substring( 0, index );
outtro = content.substring( index + w.toString().length() );
}
else
{
/*
* NOTE: Due to whitespace, attribute reordering or entity
expansion the above indexOf test can easily
* fail. So let's try harder. Maybe some day, when JDOM
offers a StaxBuilder and this builder employes
* XMLInputFactory2.P_REPORT_PROLOG_WHITESPACE, this whole
mess can be avoided.
*/
final String SPACE = \\s++;
final String XML =
\\?(?:(?:[^\']++)|(?:\[^\]*+\)|(?:'[^\']*+'))*+;
final String INTSUB =
\\[(?:(?:[^\'\\]]++)|(?:\[^\]*+\)|(?:'[^\']*+'))*+\\];
final String DOCTYPE =
!DOCTYPE(?:(?:[^\'\\[]++)|(?:\[^\]*+\)|(?:'[^\']*+')|(?: + INTSUB +
))*+;
final String PI = XML;
final String COMMENT = !--(?:[^-]|(?:-[^-]))*+--;
final String INTRO =
(?:(?: + SPACE + )|(?: + XML + )|(?: + DOCTYPE +
)|(?: + COMMENT + )|(?: + PI + ))*;
final String OUTRO = (?:(?: + SPACE + )|(?: + COMMENT +
)|(?: + PI + ))*;
final String POM = (?s)( + INTRO + )(.*?)( + OUTRO + );
Matcher matcher = Pattern.compile( POM ).matcher( content );
if ( matcher.matches() )
{
intro = matcher.group( 1 );
outtro = matcher.group( matcher.groupCount() );
}
}
}
catch ( JDOMException e )
{
throw new ReleaseExecutionException( Error reading POM: +
e.getMessage(), e );
}
catch ( IOException e )
{
throw new ReleaseExecutionException( Error reading POM: +
e.getMessage(), e );
}
ScmRepository scmRepository;
ScmProvider provider;
try
{
scmRepository =
scmRepositoryConfigurator.getConfiguredRepository( releaseDescriptor,
releaseEnvironment.getSettings() );
provider = scmRepositoryConfigurator.getRepositoryProvider(
scmRepository );
}
catch ( ScmRepositoryException e )
{
throw new ReleaseScmRepositoryException( e.getMessage(),
e.getValidationMessages() );
}
catch ( NoSuchScmProviderException e )
{
throw new ReleaseExecutionException( Unable to configure SCM
repository: +
[ANN] Maven Jar Plugin 2.4 Released
The Maven team is pleased to announce the release of the Maven Jar
Plugin, version 2.4
This plugin provides the capability to build jars.
http://maven.apache.org/plugins/maven-jar-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.4/version
/plugin
Note that this version requires Java 1.5.
Release Notes - Maven 2.x JAR Plugin - Version 2.4
** Bug
* [MJAR-69] - When 'index' and 'addClasspath' are both true, plugin fails.
** Improvement
* [MJAR-139] - New option to avoid empty jar creation
* [MJAR-148] - Add Maven version used to Created-By entry in manifest
* [MJAR-149] - Maven Jar Plugin requires JDK5
Release Notes - Maven Shared Components - Version maven-archiver-2.5
** Bug
* [MSHARED-38] - Archiver should be adding Created-By: Apache
Maven _2.0.4_ to the manifest
* [MSHARED-134] - Using ${artifcactId}-Extention-Name in MANIFEST
file can create invalid MANIFEST files
* [MSHARED-182] - manifestEntry seems not to work correctly
** Improvement
* [MSHARED-99] - Archiver should validate manifest attribute names.
* [MSHARED-221] - maven archiver requires JDK5
The list of changes in plexus is by no means complete, just focused
on changes in plexus-archiver.
Release Notes - Plexus Components - Version plexus-archiver-2.1
** Bug
* [PLXCOMP-39] - better validation of manifest entries in plexus-archiver
* [PLXCOMP-47] - Manifest entries containing line feeds are invalid
* [PLXCOMP-70] - Embedded error: String index out of range: 70
* [PLXCOMP-155] - writeManifest generates unusable MANIFEST.MF for
non-latin chars
* [PLXCOMP-177] - JarArchiver generates lines longer than 72 bytes
in MANIFEST.MF
** Task
* [PLXCOMP-172] - remove Ant's Manifest class: use JDK's class instead
Release Notes - Plexus Components - Version plexus-archiver-2.0
** Bug
* [PLXCOMP-163] - ZipFile leaks memory into native heap
* [PLXCOMP-175] - Revert to old groupId
** Improvement
* [PLXCOMP-129] - Archiver should not print info messages for
duplicate directories.
* [PLXCOMP-169] - IO Archiver forget to raise filename in case of an error
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Assembly Plugin 2.3 Released
The Maven team is pleased to announce the release of the Maven
Assembly Plugin, version 2.3
This plugin allows the user to create customized archives based on
their project and its dependencies. For example, the assembly plugin
is commonly used to create distribution archives for projects.
http://maven.apache.org/plugins/maven-assembly-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.3/version
/plugin
These release notes also contain release notes from some key dependencies.
All dependencies in assembly have been upgraded to their latest versions,
which means there are a number of thread safety issues/stability problems
that have also been fixed.
Release Notes - Maven 2.x Assembly Plugin - Version 2.3
** Bug
* [MASSEMBLY-588] - Build fails because of 'ls -1nlaR /'
* [MASSEMBLY-595] - Tar file contains world-writeable files when
fileSets with and without fileMode are mixed
** Improvement
* [MASSEMBLY-548] - Improve documentation for filters parameter
Release Notes - Maven Shared Components - Version maven-archiver-2.5
** Bug
* [MSHARED-38] - Archiver should be adding Created-By: Apache
Maven _2.0.4_ to the manifest
* [MSHARED-134] - Using ${artifcactId}-Extention-Name in MANIFEST
file can create invalid MANIFEST files
* [MSHARED-182] - manifestEntry seems not to work correctly
** Improvement
* [MSHARED-99] - Archiver should validate manifest attribute names.
* [MSHARED-221] - maven archiver requires JDK5
Release Notes - Plexus Components - Version plexus-archiver-2.1
** Bug
* [PLXCOMP-39] - better validation of manifest entries in plexus-archiver
* [PLXCOMP-47] - Manifest entries containing line feeds are invalid
* [PLXCOMP-70] - Embedded error: String index out of range: 70
* [PLXCOMP-155] - writeManifest generates unusable MANIFEST.MF for
non-latin chars
* [PLXCOMP-177] - JarArchiver generates lines longer than 72 bytes
in MANIFEST.MF
** Task
* [PLXCOMP-172] - remove Ant's Manifest class: use JDK's class instead
Release Notes - Plexus Components - Version plexus-archiver-2.0
** Bug
* [PLXCOMP-163] - ZipFile leaks memory into native heap
* [PLXCOMP-175] - Revert to old groupId
** Improvement
* [PLXCOMP-129] - Archiver should not print info messages for
duplicate directories.
* [PLXCOMP-169] - IO Archiver forget to raise filename in case of an error
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
