Re: Maven and the Apache processes...

[Tom Huybrechts]

Hi,

just one comment: wouldn't it be better if release:accept would copy the
2.0.5-rcX artifacts to 2.0.5 (like in Joakim's proposal)  instead of doing
the build again ?

Tom

On 10/14/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:



Hi,

Some comments inline.

Joakim Erdfelt wrote:
> The maven release process criticism from Dan Kulp spawned an impromptu
> ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
> and Myself) to define a better release process for maven.
>
> We covered the needs of Apache with regards to 
>
> * Apache Top Level Poms (and Incubator requirements)
> * LICENSE file and headers.
> * NOTICES.txt file requirements.
> * DISCLAIMER.txt file requirements (for incubator projects)
> * The current release plugin.
> * The desired release process.
> * The need for a staging / acceptance of a release.
>
> I'll try to cover all of these topics in as much detail as I can provide
> in this email.
>
>
===
> == APACHE POMS
>
> The incubator has requested a new incubator pom be created that extends
> off of the apache.pom
>
>   So we'll wind up with a structure like this ...
>
>   +--+
>   |  apache.pom  |
>   +--+
>   \
>++
>|  apache-incubator.pom  |
>++
>  \
>   +--+
>   |  apache-tuscany  |
>   +--+
>

Looks good. This should be generalized in the way that each ASF top level
project has a pom extending the apache pom.

>
===
> == LICENSE FILE / HEADER
>
> The LICENSE file is a unique monster in the world of apache.
> It will always be Apache v2.0.
> It needs to be in the top level of all assemblies.

Is it allowed to customize the location of the license files?
Right now assemblies are just a directory archive (in the style
of /usr/local/app/[bin|lib|etc...]. There are also assemblies
that contain an installer application; Should the license file
be in both the unpacked installer archive and in the directory structure
created by the installer?

Also, for native binary distributions (much like .deb/.rpm), applications
might be installed (in the future) in /usr/[bin|lib|...]. That would mean
the license file
is placed in /usr/.

Some applications that 3rd party libs with mixed licences often create
a 'legal' or 'licences' directory, or place all licenses in the lib/ dir.

I know this doesn't occur with Apache distributions, but maybe we need to
keep
support for this in mind for maven users.

> It needs to be in the META-INF/ directory of all jar files.
> It needs to be managed at a top level pom (not all sub modules).
>
> So I propose that we create a new top level apache pom.
>
> It will define the Apache v2.0 LICENSE file with the following contents.

[snip ASLv2]

> This file will be the basis for a new maven-license-plugin which
> provides the following functionality.

Just a note: we might want to merge with the CopyLegalFiles mojo
from Geronimo Genesis:


https://svn.apache.org/repos/asf/geronimo/genesis/trunk/plugins/tools-maven-plugin/src/main/java/org/apache/geronimo/genesis/plugins/tools

>
> * license:inject
>This is a manual goal of the license plugin to allow smart injection
> of the LICENSE contents into
>various files (with proper comments added).
>Currently identified file types.
>   *.java, *.xml, *.properties, *.jsp
> * license:check
>Using the same filetype list as license:inject, this will create a
> build-time failure if the
>license does not exist in one or more files in your project tree.

[side note: I've always disliked the licences in source files. They get
lost anyway
in the binary/compiled form; they clutter svn; the root of the project
already
defines a license that applies for all files within that directory
structure. But
the legal people probably have good reason to require this :)]

> There will also be a maven-shared-license project created to house some
> of the common license file manipulation routines so that
> maven-checkstyle-plugin and maven-project-info-reports-plugin can
> benefit from this effort also.
>
> The top level Apache pom will have a  section
> defined for jar/war plugin to
> inject the LICENSE file into the META-INF/ locations.
>
> The assembly plugin needs to have the ability to have pom managed
> content (that supplements the assembly descriptor) be injected into the
> output assembly too.  This change will allow the LICENSE file to be
> placed in the top level of the assemblies created.
>
> The top level apache.pom will also define the -sources.jar and
> -javadoc.jar creation with appropriate 

Re: Problem referencing a resource in a plugin jar

[Tom Huybrechts]

Check the value of classLoader.getResource(...). This should be a URL
in the form to a resource inside a jar. I don't think turning this
into a string and passing that to new File() will help. Instead try
using getting the resource as a stream.

InputStream is = getClass().getClassLoader().getResourceAsStream(...);
Reader reader = new InputStreamReader(is);


On 11/11/06, David Whitehurst <[EMAIL PROTECTED]> wrote:

Can someone tell me how to get the maven plugin classloader?  Or tell me if
that's I can't obtain the reference file as such ... from a plugin.java file
e.g.

ClassLoader classLoader = this.getClass().getClassLoader();
File file = new File(classLoader.getResource
(getLocalProperties().getProperty("templateName")).toString());
FileReader reader = new FileReader(file);

The templateName is a String e.g.

webstuff/mytemplate.ftl

And it resides in the plugin jar at /webstuff/mytemplate.ftl .  I checked
the jar in the .m2 repo.  Is my FileNotFoundException because I am using the
wrong classloader?  And, if so, what classloader, and how do I get it?


Thanks,

David




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

Re: [discuss] Java 5

[Tom Huybrechts]

I write all my mojo's with 1.5.
You just need to avoid using annotations and generics in the signature
of your classes (fields, methods and their annotations).

Tom

On 11/27/06, Nicolas DE LOOF <[EMAIL PROTECTED]> wrote:


Maven should depends on the latests Java version to allow plugins to use
latest technology !
The maven-plugin-tools is a good example that demonstrate some user may
get issue because maven is not up to date with latest tools.

I'm building a Java 1.3 project for Websphere 5.0 using maven under
Java5 (I'm using Java5 testing tools, like Watij). The target runtime
may be java 1.1 or JME, this has nothing to do with maven requirements.

Not beeing able to build a Java5 project/plugin with maven is a real
issue. For maven plugins to support Java5 keywords, we should update
maven requirements to Java5. Is there similar limitation not beeing able
to build Java6 project/plugin using maven ? (is there some new Java6
keyword not supported in a Jav5 environment ?)

Nico.


Emmanuel Hugonnet a écrit :
> Brett Porter a écrit :
>> This would have zero impact on applications built with Maven.
>>
>> I'd been meaning to follow this up. Let me see what happened with the
>> user survey...
>>
>> - Brett
>>
>> On 26/11/2006, at 12:49 PM, Brian E. Fox wrote:
>>
>>> Our experience with our products is that not enough of the available
>>> portal and app servers support JDK 1.5 or our customers haven't yet
>>> upgraded. That unfortunately means we are stuck on 1.4 for the near
>>> future. I think many business customers are in the same predicament
>>> where we can't dictate the JDK required. If maven suddenly required
>>> Java
>>> 1.5, we would be in a serious bind and it would limit adoption of Maven
>>> 2.1.
>>>
>>>
>>> -Original Message-
>>> From: Rahul Thakur [mailto:[EMAIL PROTECTED]
>>> Sent: Saturday, November 25, 2006 7:55 PM
>>> To: Maven Developers List
>>> Subject: Re: [discuss] Java 5
>>>
>>> This thread kinda died off silently
>>>
>>> Just wondering if there was a user survey about switching to Java 5.0?
>>>
>>> Rahul
>>>
>>>
>>> - Original Message -
>>> From: "Jason van Zyl" <[EMAIL PROTECTED]>
>>> To: "Maven Developers List" 
>>> Sent: Sunday, July 09, 2006 6:09 AM
>>> Subject: Re: [discuss] Java 5
>>>
>>>

 On 7 Jul 06, at 2:36 AM 7 Jul 06, Brett Porter wrote:

> Hi,
>
> I wanted to get thoughts on starting to require a Java 5 JVM to run
> stuff we build. We currently restrict to 1.4 across the board.
>
>

 I think before this can be done we need to make sure we're not making
 life difficult for people. It may be the case that most people don't
 have a problem using a 1.5 JDK in their environment but it might be
 an ideal time to use one of the online survey services to take a real
 poll. If the vast majority of users were not adversely affected by a
 move to 1.5 I would be fine with, as I'd like to use 1.5 where
 possible. But if it's not the case we probably should hold off on
 this requirement.

> Here's what I'm thinking:
> - MRM and Continuum should switch now. Stuff built there is rarely
> consumed elsewhere, and a Java 5 requirement outside of that is
> reasonable
> - We could switch for Maven 2.1, as long as we have improved  support
>>>
> for invoking external toolchains. This would facilitate  doing some
> much nicer stuff with plugins like annotations.
> - A generified plexus would be very cool, but is an aside here and
> post plexus-1.0 in my opinion.
> - I think it's best to keep the lower requirement on Doxia,  Surefire
>>>
> (1.3), and Wagon for now.
>
> Does anyone have any thoughts on this?
>
> I'll likely propose a vote on the first point before the first/next
> releases of them unless there are reasons not to.
>
> Cheers,
> Brett
>
> --Apache Maven - http://maven.apache.org/
> Better Builds with Maven - http://library.mergere.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

 Jason van Zyl
 [EMAIL PROTECTED]




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

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

Re: [discuss] Java 5

[Tom Huybrechts]

This plugin uses sourcelevel 1.5:

https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/repositorytools-maven-plugin


On 11/27/06, Emmanuel Hugonnet <[EMAIL PROTECTED]> wrote:

Tom Huybrechts a écrit :
> I write all my mojo's with 1.5.
> You just need to avoid using annotations and generics in the signature
> of your classes (fields, methods and their annotations).
>
> Tom
>
So maybe you can enlight me ;-) : maven-plugin-tools-java (2.0.1 to
2.0.5-SNAPSHOT) has a dependency on qdox 1.5 which is jdk 1.5
incompatible. How did you resolve this problem ?

I maybe wrong but your constraint apply to all the classes of my plugin
not just my MOJO, so this means I must code with 1.4 style :(

Emmanuel

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




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

Re: [discuss] Java 5

[Tom Huybrechts]

On 11/27/06, Tom Huybrechts <[EMAIL PROTECTED]> wrote:

This plugin uses sourcelevel 1.5:

https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/repositorytools-maven-plugin



... and it does have non-mojo classes that do not have these
constraints (see the components package)

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

Re: Tools for merging and managing repositories

[Tom Huybrechts]

The repositorytools tried to do too many things at once, and the
result was that it almost didn't work at all :)

This simple code should get you somewhere - it is an implementation of
a release plugin phase, but you can transform it into a mojo. It will
take a remote repository on the local filesystem, and deploy all the
artifacts in it.

import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.io.Reader;
import java.util.ArrayList;
import java.util.List;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

import org.apache.maven.artifact.Artifact;
import org.apache.maven.artifact.deployer.ArtifactDeployer;
import org.apache.maven.artifact.deployer.ArtifactDeploymentException;
import org.apache.maven.artifact.factory.ArtifactFactory;
import org.apache.maven.artifact.metadata.ArtifactMetadata;
import org.apache.maven.artifact.repository.ArtifactRepository;
import org.apache.maven.artifact.repository.DefaultArtifactRepository;
import org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout;
import org.apache.maven.model.Model;
import org.apache.maven.model.io.xpp3.MavenXpp3Reader;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.MojoFailureException;
import org.apache.maven.project.MavenProject;
import org.apache.maven.project.artifact.ProjectArtifactMetadata;
import org.apache.maven.settings.Settings;
import org.apache.maven.shared.release.ReleaseExecutionException;
import org.apache.maven.shared.release.ReleaseFailureException;
import org.apache.maven.shared.release.ReleaseResult;
import org.apache.maven.shared.release.config.ReleaseDescriptor;
import org.apache.maven.shared.release.phase.AbstractReleasePhase;
import org.apache.maven.wagon.repository.Repository;
import org.codehaus.plexus.util.DirectoryScanner;
import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.xml.pull.XmlPullParserException;

/**
 * @plexus.component role="org.apache.maven.shared.release.phase.ReleasePhase"
 *   role-hint="deploy-repository"
 *
 */
public class DeployRepositoryPhase extends AbstractReleasePhase {

private ArtifactRepository localRepository;
private ArtifactRepository stagingRepository;
private ArtifactRepository deploymentRepository;

/**
 * @todo replace this with a real deployment that also works remote.
 */
public ReleaseResult execute(ReleaseDescriptor releaseDescriptor,
Settings settings, List reactorProjects)
throws ReleaseExecutionException, ReleaseFailureException {
ReleaseResult result = new ReleaseResult();

try {
deploymentRepository = RepositoryUtil
.createRepository(releaseDescriptor
.getDeploymentRepository());
stagingRepository = RepositoryUtil
.createRepository(releaseDescriptor
.getTempDeploymentRepository());

localRepository = new DefaultArtifactRepository("local", new File(
releaseDescriptor.getLocalRepository()).toURL().toString(),
new DefaultRepositoryLayout());

for (Artifact a : getArtifacts(stagingRepository.getBasedir()))
deployArtifact(a.getGroupId(), a.getArtifactId(), a
.getVersion());

result.setResultCode(ReleaseResult.SUCCESS);
} catch (Exception e) {
logError(result, "Error while releasing.");
result.setResultCode(ReleaseResult.ERROR);
}
return result;

}

private List getArtifacts(String basedir) {
DirectoryScanner ds = new DirectoryScanner();
ds.setIncludes(new String[] { "**/*.pom" });
ds.setBasedir(basedir);
ds.scan();
String[] includedFiles = ds.getIncludedFiles();
List result = new ArrayList();
for (String s : includedFiles) {
s = s.substring(0, s.lastIndexOf(File.separatorChar));
int i = s.lastIndexOf(File.separatorChar);
String version = s.substring(i + 1);
s = s.substring(0, i);
i = s.lastIndexOf(File.separatorChar);
String artifactId = s.substring(i + 1);
String groupId = s.substring(0, i).replace(File.separatorChar, '.');
Artifact artifact = artifactFactory.createArtifactWithClassifier(
groupId, artifactId, version, "pom", null);
result.add(artifact);
System.out.printf("%s %s %s\n", groupId, artifactId, version);
}
return result;

}

public ReleaseResult simulate(ReleaseDescriptor releaseDescriptor,
Settings settings, List reactorProjects)
throws ReleaseExecutionException, ReleaseFailureException {
ReleaseResult result = new ReleaseResult();
result.setResultCode(

MavenEmbedder says "cannot lookup required component"

[Tom Huybrechts]

I'm trying to integrate Maven into a STAF [1] service using the
embedder (the latest 2.1 snapshot).

During startup, the embedder gives me this exception:

org.apache.maven.embedder.MavenEmbedderException: Cannot lookup
required component.
at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:647)
at 
org.apache.maven.embedder.MavenEmbedder.(MavenEmbedder.java:194)
at com.agfa.staf.MyStafService.createEmbedder(MyStafService.java:149)
at com.agfa.staf.MyStafService.resolveArtifact(MyStafService.java:156)
at com.agfa.staf.MyStafService.handleRegister(MyStafService.java:63)
at com.agfa.staf.MyStafService.acceptRequest(MyStafService.java:44)
at 
com.ibm.staf.service.STAFServiceHelper.callService(STAFServiceHelper.java:349)
Caused by: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component reposito
ry: org.apache.maven.Maven [default] (lookup realm:
ClassRealm[plexus.core, parent: null]).
at 
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:139)
at 
org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:69)
at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:247)
at 
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:241)
at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:595)
... 6 more

The code that starts the embedder looks like this:

Configuration configuration = new DefaultConfiguration();
ClassLoader loader = MavenEmbedder.class.getClassLoader();
configuration.setClassLoader(loader);
configuration.setMavenEmbedderLogger(new 
MavenEmbedderConsoleLogger());

ConfigurationValidationResult validation = MavenEmbedder
.validateConfiguration(configuration);
if (!validation.isValid()) {
throw new RuntimeException("Not valid");
}
MavenEmbedder embedder = new MavenEmbedder(configuration);


This code works when I run it in a normal environment (both my code
and the embedder on the CLASSPATH) but fails with the above exception
when running it as a STAF service. The difference between these
environments is that the STAF service has a special classloader. A
STAF service jar looks like this:

/STAF-INF/classes: contains classes
/STAF-INF/jars: contains extra libs ( maven-embedder.jar )

This is the classloader used:
http://staf.cvs.sourceforge.net/staf/src/staf/lang/java/service/STAFServiceJarClassLoader.java?revision=1.14&view=markup


Does anybody know what the problem is here ? Does the embedder or
Plexus expect its code in an ordinary jar ?

Tom

[1] Software Testing Automation Framework at
http://staf.sourceforge.net/index.php

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

Re: Javapolis 2007

[Tom Huybrechts]

I'll be there too.

On Nov 27, 2007 11:40 AM, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> ZZzzz. Anyone awake?
>
> Vincent M., read your mail. I know you're coming!
>
> Stéphane
>
>
> On Nov 25, 2007 11:32 AM, Stephane Nicoll <[EMAIL PROTECTED]> wrote:
> > Just wondering who's coming to Javapolis in two weeks?
> >
> > I'll be there so if you're coming, let me know :)
> >
> > Stéphane
> >
> > --
> > Large Systems Suck: This rule is 100% transitive. If you build one,
> > you suck" -- S.Yegge
> >
>
>
>
> --
> Large Systems Suck: This rule is 100% transitive. If you build one,
> you suck" -- S.Yegge
>
> -
> 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]

jasperreports 2.0.3 upload

[Tom Huybrechts]

Hi,

could somebody have a look at
http://jira.codehaus.org/browse/MAVENUPLOAD-1852 please ?

Thanks,

Tom

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

Re: what's up with "artifactHandler.isAddedToClasspath()" ?

[Tom Huybrechts]

It's set in the ArtifactHandler configuration in components.xml.


On Dec 27, 2007 9:12 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:

> I'm debugging a problem that happens in both 2.0.8/9-SNAPSHOT and
> 2.1-SNAPSHOT...that is project.getRunTimeArtifacts returns an empty list
> even when it clearly should not. I debug into the project and I see that
> all the getXXXArtifacts make a call like this:
>
>
>
>  if ( a.getArtifactHandler().isAddedToClasspath() )
>
>{
>
>
>
>
>
> The trouble is, I cannot find any place that the backing variable
> addedToClasspath is set.  (and it's not exposed via a setter in the
> ArtifactHandler interface) Am I blind or is there something else going
> on here? It seems to me like all these new get[Scope]Artifacts must be
> broken.
>
>
>
> --Brian
>
>

Re: Reading another plugins configuration: there's a patch available that does this

[Tom Huybrechts]

On Dec 28, 2007 1:02 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

> Hi
>
> I've been applying patches to the pmd-plugin from Xavier Le Vourch. The
> patches have been of good quality.
>
> Now I'm looking at a patch for http://jira.codehaus.org/browse/MPMD-63
> which reads the jdk source level from the compiler-plugin, so that it
> can feed this info to PMD. This topic has been brought up from time to
> time and the only answer I have seen is: "No there is no standard way of
> doing this".
>
> The code seems pretty straight-forward to me, but I wanted to check with
> you before I apply it. Here's a run down of what it does:
>
> - Get the build/plugins from the pmd-plugins project model
> - Pick out "org.apache.maven.plugins:maven-compiler-plugin"
> - Create a DOM document of the plugin's configuration
> - Use XPath to retrieve the "source" configuration
>
> Is this a good/ok/bad thing to do?
>
> --
> Dennis Lundberg
>

Won't work if you have an alternative lifecycle where the
maven-compiler-plugin is not responsible for compilation...

Tom


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

Re: Request help on MCLIRR-7

[Tom Huybrechts]

On Jan 8, 2008 10:56 PM, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have evaluated the bug report MCLIRR-7 and must admit that I am
> stuck. Here's what I have found:
>
> Clirr requires two classloaders, one with the previous version and one
> with the current version. In order to create the first classloader,
> the clirr-maven-plugin does the following:
>
> - Resolves an artifact from the repositories. (For example
> commons-fileupload-1.2.)
> - Invokes the following snipped with the artifact:
>
>// TODO: better way? Can't use previousArtifact as the
> originatingArtifact, it culls everything out
>// perhaps resolve the artifact itself (not the pom artifact),
> then load the pom and get dependencies
>Artifact dummy = factory.createProjectArtifact( "dummy", "dummy", "1.0" );
>ArtifactResolutionResult result = resolver.resolveTransitively(
> previousArtifacts,
>dummy, localRepository, project.getRemoteArtifactRepositories(),
>metadataSource, null );
>
> The problem is that the result doesn't contain any artifacts, not even
> the "previous version" artifact, which is in the previousArtifacts
> collection.
>
> Any idea what's wrong or what I might try instead?
>

Take a look at the developer cookbook (
http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook )
and search for "resolving transitively".
That code works for me.

>
> Thanks,
>
> Jochen
>
>
> --
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Request help on MCLIRR-7

[Tom Huybrechts]

On Jan 9, 2008 9:23 AM, Jorg Heymans <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 11:02 PM, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
>
> Take a look at the developer cookbook (
> > http://docs.codehaus.org/display/MAVENUSER/Mojo+Developer+Cookbook )
>
>
> It would make sense to create a link from
> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html to
> this page. I did not know about its existence until now (thanks Tom), mainly
> because Google does not list it on any mojo related search.

There's a link to plugin cookbook here:
http://maven.apache.org/plugin-developers/index.html
but it's pointing to a "coming soon" page.


>
> Jorg
>

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

Re: Zip packaging in 2.0.x (MNG-1683)

[Tom Huybrechts]

Are you proposing to add the zip packaging to the core ?
Won't this break (or at least change) builds that have defined their
own zip packaging ?

Tom

On Jan 9, 2008 10:06 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:
> Hi,
> I have just read a thread [1] on the user mailing list.
> Is there any objections if I reopen the issue [2] and fix it in the
> 2.0.x branch ?
> A new plugin (maven-zip-plugin) will be added too.
>
> Thoughts ?
>
> Thanks,
> --
> Olivier
>
> [1] 
> http://www.nabble.com/Existance-of-ZIP-Archetype--%7C-How-to-distribute-DB-code-to-different-mvn-modules--td14614465s177.html
> [2] http://jira.codehaus.org/browse/MNG-1683
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Dramatically speed up dependency resolution

[Tom Huybrechts]

I just tried it out and sometimes got this error halfway through a build:

Exception in thread "pool-101-thread-2"
java.lang.ArrayIndexOutOfBoundsException: 10
at java.util.ArrayList.add(ArrayList.java:352)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver$ResolveArtifactTask.resolveArtifact
(DefaultArtifactResolver.java:400)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver$ResolveArtifactTask.run
(DefaultArtifactResolver.java:387)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

The exact location and the array index changed, but the stacktrace was
always the same.


On Jan 27, 2008 12:06 PM, Don Brown <[EMAIL PROTECTED]> wrote:

> One of my pain points with Maven is how slow it is to "download the
> internet", so rather than bitch (or more accurately, continue
> bitching), I decided to do something about it.  I created a customized
> build of Maven 2 (MNG-3379, WAGON-98) that, at least in my simple
> tests, cut the dependency resolution time down by as much as 40%.
>
> Two key components to this speedup:
>  * Connection pooling: Uses the http wagon instead of http-lightweight
> and fixed incorrect http client initialization
>  * Parallel resolution of artifacts - Uses a thread worker pool to
> parallelize artifact resolution
>
> I had hoped to make this change as a plugin, but I had to hack a bit
> in the core of Maven and Wagon to get it to work correctly.  The patch
> as provided has a few disadvantages:
>
> * Requires Java 5, but the backport jars could be substituted pretty
> easily
> * Breaks some plugins due to commons-logging being in the Maven uber
> jar (required by commons-httpclient), notably the apt plugin (maybe
> more should use the isolatedRealm setting?)
> * Screws up the progress monitor as multiple threads are updating it
>
> Anyways, it'd be cool to get a version of this in Maven, but until
> then, if you want to give it a go, I put the uber jar up on my Apache
> space.  I should be a drop-in replacement for any recent version of
> Maven (tested with 2.0.7):
>
> http://people.apache.org/~mrdon/maven-2.0.9-SNAPSHOT-uber.jar
>
> Don
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Dramatically speed up dependency resolution

[Tom Huybrechts]

Did you build this on java 6?

I'm getting bad class version errors on java 5:

+ Error stacktraces are turned on.
-
this realm = plexus.core
urls[0] = file:/c:/dev/tools/maven/lib/maven-2.0.9-SNAPSHOT-uber.jar
Number of imports: 0
-
FATAL ERROR: Unable to configure the Maven application
Error stacktrace:
org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Unable to lookup component 'org.apache.maven.artifact.repository.Artifact
RepositoryFactory', it could not be created
at org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.java:335)
at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78)
at org.apache.maven.cli.MavenCli.createLocalRepository(MavenCli.java
:489)
at org.apache.maven.cli.MavenCli.createRequest(MavenCli.java:412)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by:
org.codehaus.plexus.component.factory.ComponentInstantiationException: Could
not instanciate component: role: 'org.apache.maven.artifact.re
pository.ArtifactRepositoryFactory', implementation: '
org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory'
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException
(JavaComponentFactory.java:77)
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(
JavaComponentFactory.java:62)
at
org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(
DefaultPlexusContainer.java:1464)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance
(AbstractComponentManager.java:93)
at
org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent
(ClassicSingletonComponentManager.java:92)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(
DefaultPlexusContainer.java:331)
... 12 more
Caused by: java.lang.UnsupportedClassVersionError: Bad version number in
.class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(
SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(
RealmClassLoader.java:195)
at org.codehaus.classworlds.DefaultClassRealm.loadClass(
DefaultClassRealm.java:255)
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(
JavaComponentFactory.java:30)
... 16 more

On Jan 28, 2008 12:42 PM, Don Brown <[EMAIL PROTECTED]> wrote:

> On 1/28/08, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
> > I just tried it out and sometimes got this error halfway through a
> build:
>
> Doh, forgot to synchronize the resolved and missing artifact lists,
> now that they can be accessed by multiple threads.  I put up a new
> version (has that and a few pool optimizations) at the same location:
>
> http://people.apache.org/~mrdon/maven-2.0.9-SNAPSHOT-uber.jar<http://people.apache.org/%7Emrdon/maven-2.0.9-SNAPSHOT-uber.jar>
>
> Don
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: svn commit: r609944 - in /maven/components/branches/maven-2.0.x/maven-core/src: main/java/org/apache/maven/cli/MavenCli.java test/java/org/apache/maven/cli/MavenCliTest.java

[Tom Huybrechts]

While using a 2.0.9 snapshot, I noticed that my plugins no longer see -D...
cli arguments as system properties.
Probably because System.setProperty(...) was removed in this revision. Why
was this necessary ?

Tom


On Jan 8, 2008 1:03 PM, <[EMAIL PROTECTED]> wrote:

> Author: vsiveton
> Date: Tue Jan  8 04:03:02 2008
> New Revision: 609944
>
> URL: http://svn.apache.org/viewvc?rev=609944&view=rev
> Log:
> MNG-2848: Environment variables in profile activation not working
> Submitted by: Richard van der Hoff
> Reviewed by: Vincent Siveton
>
> o patch applied with a small fix for env.PATH in the test
>
> Modified:
>maven/components/branches/maven-2.0.x
> /maven-core/src/main/java/org/apache/maven/cli/MavenCli.java
>maven/components/branches/maven-2.0.x
> /maven-core/src/test/java/org/apache/maven/cli/MavenCliTest.java
>
> Modified: maven/components/branches/maven-2.0.x
> /maven-core/src/main/java/org/apache/maven/cli/MavenCli.java
> URL:
> http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-core/src/main/java/org/apache/maven/cli/MavenCli.java?rev=609944&r1=609943&r2=609944&view=diff
>
> ==
> --- 
> maven/components/branches/maven-2.0.x/maven-core/src/main/java/org/apache/maven/cli/MavenCli.java
> (original)
> +++ 
> maven/components/branches/maven-2.0.x/maven-core/src/main/java/org/apache/maven/cli/MavenCli.java
> Tue Jan  8 04:03:02 2008
> @@ -23,9 +23,11 @@
>  import java.io.IOException;
>  import java.io.InputStream;
>  import java.util.ArrayList;
> +import java.util.Iterator;
>  import java.util.List;
>  import java.util.Properties;
>  import java.util.StringTokenizer;
> +import java.util.Map.Entry;
>
>  import org.apache.commons.cli.CommandLine;
>  import org.apache.commons.cli.CommandLineParser;
> @@ -63,6 +65,7 @@
>  import org.codehaus.plexus.logging.Logger;
>  import org.codehaus.plexus.logging.LoggerManager;
>  import org.codehaus.plexus.util.Os;
> +import org.codehaus.plexus.util.cli.CommandLineUtils;
>  import org.codehaus.plexus.util.xml.pull.XmlPullParserException;
>
>  /**
> @@ -221,7 +224,7 @@
> // TODO:Additionally, we can't change the mojo level
> because the component key includes the version and it isn't known ahead of
> time. This seems worth changing.
> }
>
> -ProfileManager profileManager = new DefaultProfileManager(
> embedder.getContainer(),System.getProperties() );
> +ProfileManager profileManager = new DefaultProfileManager(
> embedder.getContainer(), executionProperties );
>
> if ( commandLine.hasOption( CLIManager.ACTIVATE_PROFILES ) )
> {
> @@ -561,10 +564,27 @@
> // System properties handling
> //
> --
>
> -private static Properties getExecutionProperties( CommandLine
> commandLine )
> +static Properties getExecutionProperties( CommandLine commandLine )
> {
> Properties executionProperties = new Properties();
>
> +// add the env vars to the property set, with the "env." prefix
> +// XXX support for env vars should probably be removed from the
> ModelInterpolator
> +try
> +{
> +Properties envVars = CommandLineUtils.getSystemEnvVars();
> +Iterator i = envVars.entrySet().iterator();
> +while ( i.hasNext() )
> +{
> +Entry e = (Entry) i.next();
> +executionProperties.setProperty( "env." + 
> e.getKey().toString(),
> e.getValue().toString() );
> +}
> +}
> +catch ( IOException e )
> +{
> +System.err.println( "Error getting environment vars for
> profile activation: " + e );
> +}
> +
> //
> --
> // Options that are set on the command line become system
> properties
> // and therefore are set in the session properties. System
> properties
> @@ -611,13 +631,6 @@
> }
>
> executionProperties.setProperty( name, value );
> -
> -//
> --
> -// I'm leaving the setting of system properties here as not to
> break
> -// the SystemPropertyProfileActivator. This won't harm embedding.
> jvz.
> -//
> --
> -
> -System.setProperty( name, value );
> }
>
> //
> --
>
> Modified: maven/components/branches/maven-2.0.x
> /maven-core/src/test/java/org/apache/maven/cli/MavenCliTest.java
> URL:
> http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-core/src/test/java/org/apache/maven/cli/MavenCliTest.java?rev=609944&r1=609943&r2=609944&view=diff
>
> ==

import scope questions

[Tom Huybrechts]

I read about the new import scope in the 2.0.9 release notes. This
looks very promising to me, but I have a questions on the details of
how this works.
I looked in the mailing list history for discussions on this feature,
but couldn't find anything. There is a wiki page, but it has few
details (and no discussion).

I've set up a few simple test projects:
- project-A has a managed dependency for log4j:log4j:1.2.13
- project-B has a managed dependency for log4j:log4j:1.2.14
- project-C imports managed dependencies from A and B, and has a
version-less dependency on log4j:log4j.

What version of log4j is now used by project-C ? It looks like this
now depends on the order of the imports. If project-A is first in the
dependency list, it will be 1.2.13, and if project-B is first it is
1.2.14. If project-C defines it own managed dependency for
log4j:log4j, then that wins always, irrespective of ordering.
Is this the intended behaviour ?

I then extended these POMs.
- project-A got a module a1, and a managed dependency for a1. Then I
released versions 1 and 2 of project-A and a1.
- project-B gets a managed dependency on version 1 of a1.
- project-C gets a version-less dependency on a1, and the managed
dependency on project-A is updated to version 2.

I want to import the parent project-A to avoid having to set
dependency versions for all of project-A's modules. This would be very
useful to increase manageability.
But as I kind of expected, the version of a1 in project-C is still
dependent on ordering.
If project-B (which depends on a1:1) is listed first, project-C will
depend on a1:1 too. Even though I have a direct dependency import for
project-A:2.
Someone else mentioned the principle of least surprise recently. This
was defnitely violated for me here :(

One last thing I wanted to check is how this would interact with older
Maven versions, so I created project-D that depends on project-C.
With 2.0.9 dependency:tree on project-D nicely prints the transitive
dependencies on log4j and a1.
But switching back to 2.0.8, I get:
 [WARNING] POM for 'x:project-C:pom:1:compile' is invalid. It will be
ignored for artifact resolution. Reason: Failed to validate POM for
project x:project-C at Artifact [x:project-C:pom:1:compile]
and the transitive dependencies are gone.
Does this mean we'll start seeing dependencies in the repository that
cannot reliably be used by older Maven versions ?

Tom

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

Re: Plugin development & plexus-utils version

[Tom Huybrechts]

That's way too much magic. I'd rather have an explicit
true\false flag.
dependency:analyze could check this if desired.

On Wed, Apr 30, 2008 at 4:31 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> It seems like we would need an ASM based post processor to analyze it before 
> generating the pom that gets deployed.
>
>
> -Original Message-
> From: William Ferguson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 29, 2008 7:01 PM
> To: Maven Developers List; [EMAIL PROTECTED]
> Subject: Re: Plugin development & plexus-utils version
>
> As Benjamin points out at the end of that Jira, the current behaviour is 
> there to deal with use of libraries containing classes that extend classes in 
> other libraries.
>
> Seems to me that we need a way to differentiate in our projects which 
> dependencies need to get *exported* as compile dependencies and which can get 
> exported as runtime depedencies.
>
> Projects that don't use implementation inheritance will be able to trim down 
> their exported compile time dependencies to nil.
>
> Implementation inheritance of any class relegates that class's library to 
> being exported as a compile time dep, otherwise the library is exported as a 
> runtime dep.
>
> William
>
>
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jörg Schaible
> > Sent: Wednesday, 30 April 2008 7:20 AM
> > To: dev@maven.apache.org
> > Subject: Re: Plugin development &
> > plexus-utils version - Sender is forged (SPF Fail)
> >
> > Well, I requested long ago a setting for maven to inherit all
> > deps as runtime by default ... :-)
> >
> > http://jira.codehaus.org/browse/MNG-2589
> >
> > - Jörg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: stage:copy ClassCastException with maven 2.0.9

[Tom Huybrechts]

I have a private plugin that uses the stage-plugin code, and just got
the same stacktrace from one of my users yesterday.
Probably also because he switched to 2.0.9. I'll ask him on monday...


On Sat, May 17, 2008 at 8:50 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> That's weird. I used 2.0.9 to stage and release 2.0.9
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Olivier Lamy
> Sent: Saturday, May 17, 2008 10:12 AM
> To: Maven Developers List
> Subject: stage:copy ClassCastException with maven 2.0.9
>
> Hi,
> I have just try to stage the maven-invoker and I have the following
> exception :
>
> [INFO]
> 
> [INFO] org.apache.maven.wagon.providers.ssh.jsch.ScpWagon
> [INFO]
> 
> [DEBUG] Trace
> java.lang.ClassCastException:
> org.apache.maven.wagon.providers.ssh.jsch.ScpWagon
>at
> org.apache.maven.plugins.stage.DefaultRepositoryCopier.copy(DefaultRepos
> itoryCopier.java:252)
>at
> org.apache.maven.plugins.stage.CopyRepositoryMojo.execute(CopyRepository
> Mojo.java:93)
>at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa
> nager.java:451)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default
> LifecycleExecutor.java:558)
>at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa
> l(DefaultLifecycleExecuto
>
> The workaround was to use maven 2.0.8.
>
> --
> Olivier
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: What is the official Eclipse repo layout (was: How to use central repo into an Eclipse project?)

[Tom Huybrechts]

Here's my 2c.

- Bundle-SymbolicName = artifactId is a no-brainer IMHO
- groupId should be the organization creating the bundle (so when
converting an existing library, the organization that does the
converting)
- Bundle-Version = version - somebody once proposed dropping the
qualifier but then you loose tracability

- The generated POMs are also open for debate. I believe
ecipse:to-maven only looks at the manifest and generates dependencies
from Require-Bundle, but it ignores Import-Package headers. For
versions it creates Maven ranges, but these were unusable without
specifying a zillion excludes (at least in 2.0.8). My approach with
Tycho is different. I would start with a consistent install (e.g. the
full Ganymede release). Tycho's uploader will first perform resolve
these bundles against each other using OSGi rules, to decide what the
actual dependencies are. The POM dependencies are calculated based on
this dependency graph.

- For RCP developers, we should also decide what the Eclipse features
should look like in the repository. E.g. upload a full feature zip or
just a POM that has dependencies on all the member plugins

- Regarding all the different bundleizations (is that a word?) that
are or will be available for some common libraries: I'm afraid this
will only be solved when libraries start producing OSGi artifacts
themselves. Perhaps the new spring osgi repository will also help to
standardize.

Tom

On Thu, May 22, 2008 at 6:59 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> On 22/05/2008, at 2:48 PM, Jason van Zyl wrote:
>
>>
>> On 21-May-08, at 9:23 PM, Barrie Treloar wrote:
>>
>>> On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:

 It's not very complicated what we discussed. Essentially it's artifactId
 =
 symbolic bundle id because you'll never be able to derive the
 artifactId/groupId pair from a symbolic bundle id because you don't know
 where to split it. So avoid the complication of the mapping. The groupId
 would be use for organization in the repository but not important in the
 creation of the symbolic bundle id. What this means is that you could
 directly retrieve a bundle into a running osgi container without trying
 to
 synthesize the bundle id which is a good thing.
>>>
>>> Next question then,
>>>
>>> when can we seed a maven repository with bundles?
>>>
>>
>> Officially? When we agree. This was a casual discussion we had at
>> EclipseCon. Probably wouldn't take long. I imagine most issues could be
>> hashed out in a week and then we could try it in a test repository on
>> central.
>
> Sounds like a good approach to me. Perfect timing with the Ganymede release
> coming up soon - we could get that release in there, and get it right from
> there on.
>
> So far the proposal seems to be:
> - use artifact IDs that most match the final identifiers
> - discourage the use of http://repo1.maven.org/eclipse/ and
> http://repo1.maven.org/maven2/org/eclipse/ with the old artifact IDs
>
> The questions I have so far:
>
> Are the POMs generated by today's eclipse:to-maven goal the right ones to be
> using? I'm particularly wondering about the version range issue Vincent
> raised.
>
> What is the policy on bundle-ized versions of existing artifacts? The above
> sounds good for org.eclipse itself, but having stuff like this is worrying:
> http://repo1.maven.org/eclipse/org/apache/ant/org.apache.ant/1.6.5/
> Worrying because we start duplicating an awful lot of stuff. Is it possible
> we could place the OSGi manifest in the repository alongside main ant and
> the build process could merge them? And for artifacts that don't have them,
> we can generate default OSGi manifest information if incorporated into such
> a build?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Developing Maven 2.1

[Tom Huybrechts]

On Mon, Jul 7, 2008 at 5:47 PM, John Casey <[EMAIL PROTECTED]> wrote:
>
>
> Jason van Zyl wrote:
>>
>> There are groups there for Maven 2.1, Plexus, Maven IDE (really embedder
>> consumers), and I will also limit the plugins to the default lifecycles of
>> the commonly used packagings like JAR, and WAR. John has also started
>> creating automated ways to release to stage, and subsequent promotion upon
>> success. So for any component in the tool chain there will be a way to do a
>> consistent release from a canonical machine.
>
> Just for posterity (if we're going to be using this as an official release
> vector for the entire project):
>
> Jason's referring to a ruby script I wrote to lookup the version string for
> a particular staged project, for use in the stage:copy mojo. This allows us
> to setup generic promotion scripts in a CI environment like Hudson. I've
> committed this script to:
> https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.
>
> The rest of this release infrastructure has simply been configuration of
> hudson and nexus - nexus, to provide a staging ground for releases - to
> configure release jobs that deploy to this staging location instead of the
> real release repository...just generalizing on configuration that we all
> have in our personal settings.xml files by now. Jason's credentials are used
> for SVN and SSH where necessary, and I've created a new GPG key for use in
> this CI system, then signed it with my own key.  That key ID is: 84B54612.
>
> To echo Jason, the goal here is to create an environment that - if not
> perfectly flawless - is at least a known quantity. Just as we've moved in
> the direction of pointing to our CI servers as the definitive point of
> reference for our unit and integration tests (though we're not quite there
> yet), we need to be releasing Maven artifacts from a similarly definitive
> environment. In principle, the configuration and script I've written (above)
> should enable any team to enable a similar release infrastructure for their
> own projects.
>
> -john
>>

I tried to automate part of the Maven release process (including
staging a release and voting on it) as a demo of Hudson-JBPM
integration.
This is a work in progress, but if you're interested, you can find
more info at http://hudson.gotdns.com/wiki/display/HUDSON/JBPM+Plugin

Tom

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

Re: Developing Maven 2.1

[Tom Huybrechts]

There's a setup section on the wiki page which has the necessary info
on setting up Hudson.
The staging plugin is part of the 'tom' branch which is linked to from the page.

On Tue, Jul 8, 2008 at 9:59 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> Is the code anywhere?
>
> I'm interested in the process, but have gone down the Drools workflow way,
> and I'm trying to work on the promotion from Nexus. But I'll definitely take
> a look at code.
>
> On 8-Jul-08, at 3:40 PM, Tom Huybrechts wrote:
>
>> On Mon, Jul 7, 2008 at 5:47 PM, John Casey <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>> Jason van Zyl wrote:
>>>>
>>>> There are groups there for Maven 2.1, Plexus, Maven IDE (really embedder
>>>> consumers), and I will also limit the plugins to the default lifecycles
>>>> of
>>>> the commonly used packagings like JAR, and WAR. John has also started
>>>> creating automated ways to release to stage, and subsequent promotion
>>>> upon
>>>> success. So for any component in the tool chain there will be a way to
>>>> do a
>>>> consistent release from a canonical machine.
>>>
>>> Just for posterity (if we're going to be using this as an official
>>> release
>>> vector for the entire project):
>>>
>>> Jason's referring to a ruby script I wrote to lookup the version string
>>> for
>>> a particular staged project, for use in the stage:copy mojo. This allows
>>> us
>>> to setup generic promotion scripts in a CI environment like Hudson. I've
>>> committed this script to:
>>> https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts.
>>>
>>> The rest of this release infrastructure has simply been configuration of
>>> hudson and nexus - nexus, to provide a staging ground for releases - to
>>> configure release jobs that deploy to this staging location instead of
>>> the
>>> real release repository...just generalizing on configuration that we all
>>> have in our personal settings.xml files by now. Jason's credentials are
>>> used
>>> for SVN and SSH where necessary, and I've created a new GPG key for use
>>> in
>>> this CI system, then signed it with my own key.  That key ID is:
>>> 84B54612.
>>>
>>> To echo Jason, the goal here is to create an environment that - if not
>>> perfectly flawless - is at least a known quantity. Just as we've moved in
>>> the direction of pointing to our CI servers as the definitive point of
>>> reference for our unit and integration tests (though we're not quite
>>> there
>>> yet), we need to be releasing Maven artifacts from a similarly definitive
>>> environment. In principle, the configuration and script I've written
>>> (above)
>>> should enable any team to enable a similar release infrastructure for
>>> their
>>> own projects.
>>>
>>> -john
>>>>
>>
>> I tried to automate part of the Maven release process (including
>> staging a release and voting on it) as a demo of Hudson-JBPM
>> integration.
>> This is a work in progress, but if you're interested, you can find
>> more info at http://hudson.gotdns.com/wiki/display/HUDSON/JBPM+Plugin
>>
>> Tom
>>
>> -
>> 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
> --
>
> Three people can keep a secret provided two of them are dead.
>
>  -- Unknown
>
>
> -
> 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]

descriptions for plugins

[Tom Huybrechts]

Hi all,

I'm looking forward to the upcoming plugin releases. Maybe this is a
good time to fix the description elements in the POMs. Right now there
are none, so they have an inherited value of ''Maven Plugins'.

Tom

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

Re: Is this still an issue?

[Tom Huybrechts]

This is stil an issue. When running a goal outside a project, the
profiles in settings.xml are ignored, (including any custom repository
you might have set up.

There is a workaround (see ARCHETYPE-1) : you need to add
-DremoteRepositories=http://the.url.to.my.repository

Tom

On 12/3/06, David Whitehurst <[EMAIL PROTECTED]> wrote:

Is this still an issue?  I don't understand the comments.

http://jira.codehaus.org/browse/MNG-2261;jsessionid=atZK5r5j2N8bRm0-m5

I want to use an archetype for AppFuse in our local repository but it keeps
defaulting to the Maven one and never looks in ours.

Suggestions?


Thanks,

David




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

Re: How to get the sources?

[Tom Huybrechts]

These sources are generated at build time.
Check out that project and build it.

Tom

On 12/3/06, Maurício Linhares <[EMAIL PROTECTED]> wrote:

Hi guys,

I'm making some bugfixes and improvements on M2Eclipse plugin, but I also
need to checkout the Maven 2 sources, specially the "maven-model" module,
but I just can't find the module's source files. Looking for the mudule via
SVN there's just a "site" folder, and no "main" or "test" folder ->
https://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.4/maven-model/src/

So, where are the source files for this module?

--
Mauricio Linhares - http://maujr.org/
Felicidade é um caminho, não o fim.
Grupo de Usuários Java da Paraíba - http://pbjug.org/
Aprenda filosofia para a vida - http://www.nova-acropole.org.br/
João Pessoa, PB, (83) 3231-5419



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

Re: maven2 repository of eclipse jars

[Tom Huybrechts]

Please consider http://jira.codehaus.org/browse/MECLIPSE-201 if you
want to deploy these artifacts to central. Once the POMs are out
released, they can't be changed untill there is a new release.

Would'nt it be a good idea to try to involve people from Eclipse in this ?

Tom

On 12/11/06, Graham Leggett <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:

> that sounds good and can be setup as if it were another mirror, the
> important questions
> who will volunteer to do it?
> is enough people asking for them that it makes sense?

In theory, keeping such a repository up to date could be done from a
zone, and it's not a problem for me to set up (having already figured
out the details), but the repository itself contains Eclipse code -
would ibiblio host a mirror of such a thing?

Regards,
Graham
--





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

Re: maven2 repository of eclipse jars

[Tom Huybrechts]

- last but not least: package-level dependencies can't be handled by
maven as is. IMHO this could not be a big problem at the moment: you
could be forced to manually add transitive dependencies  but at the
end it doesn't really hurt (BTW, in eclipse builds package-level
dependencies are very rare)



In any Eclipse install, each Import-Package is provided by at least
one bundle, and you can make a POM dependency on that bundle. It is
quite easy to implement this by feeding all bundles in the install
into the resolver and having it calculate the package wiring. This
buys you one more thing: you can automatically validate if the install
is consistent.

Tom

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

Re: maven2 repository of eclipse jars

[Tom Huybrechts]

On 12/11/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:

On 12/11/06, Tom Huybrechts <[EMAIL PROTECTED]> wrote:
> In any Eclipse install, each Import-Package is provided by at least
> one bundle, and you can make a POM dependency on that bundle. It is
> quite easy to implement this by feeding all bundles in the install
> into the resolver and having it calculate the package wiring. This
> buys you one more thing: you can automatically validate if the install
> is consistent.

this is only true with the main eclipse platform distribution, it's
not so easy for anything that depends on other projects. Take WTP,
birt, emf, get or anything else... they could depend on anything in
the target platform or in other projects: you will be able to find a
matching bundle only by deploying the whole callisto or europa
coordinated build together (and it will not so easy neither in that
way, since there are still some duplicate jars with slightly different
versions)



It's true that you couldn't do a deploy of say WTP without having its
dependencies available. I have a target platform POM for this (which
only gathers dependencies to all Eclipse artifacts I have deployed
previously). The state is then calculated over the target platform and
the new dependencies. If there are duplicates, the resolving process
will pick one - the same one that would be used at runtime.


fabrizio

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




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

Re: maven2 repository of eclipse jars

[Tom Huybrechts]

On 12/12/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 11 Dec 06, at 10:25 PM 11 Dec 06, Scott Lewis wrote:

> Hi Jason,
>
>
> What is the State resolver?

Dependency resolver. Basically a state machine that consumes OSGi
dependency information, determines what's missing and asks for more.
How the conditions are satisfied is up to the implementation and I
believe this is what varies across usage. This is what I was going to
try and plug into Maven to make it understand OSGi dependencies.

> Is this a name for the PDE code that manages the meta info for a
> plugin/feature (e.g. manifest.mf, plugin.xml, etc)?  To your
> knowledge is there a PDE and/or platform bug against this
> particular need/use case?  If so, what is it?  I did a quick search
> for 'state resolver' in Eclipse classification, but nothing that
> sounded like what you are describing came up.
>

I have no idea what's in there. I've always just chatted with Jeff
about it.

>>
>>> The PDE currently does all this and the Jeff is the lead for the
>>> Equinox team (which also includes Pascal Rapicault, one of the
>>> PDE developers along with others connected with the Equinox
>>> team).  As far as I know doesn't have any outstanding work items
>>> to do anything specific to unifying things for Maven.
>>
>> It's not for Maven, it's something that would benefit Eclipse and
>> Maven would be a by product beneficiary. I asked "where's the
>> code", to which he replied "well, in several places". So in order
>> for us to consume it there would have to be something concrete we
>> could use. What Eugene has now is workable for non-OSGi developers
>> but won't cut it otherwise.
>>
>>> I'm meeting/seeing Jeff on Wednesday am at foundation BOD
>>> meeting, so if there is some required change to the PDE or
>>> Equinox then I would be happy to speak with him about it
>>> directly.  But I would need to understand what exactly was
>>> required of them and why, as I have spoken with Jeff about Maven
>>> integration before.
>>
>> Unify your State resolver code so we can use it. That's it really.
>
> I'm just trying to understand this...what would it mean in
> refactoring/code restructuring terms to 'unify the state resolver
> code'?  I believe that the code that parses the plugin and feature
> models (i.e. the inter-bundle and inter-feature dependency
> information in manifest.mf, plugin.xml, feature.xml, etc) is likely
> spread across multiple bundles/plugins, but I believe the
> buckminster folks are using these APIs successfully...

Information from a manifest or a plugin.xml can be sources for the
state resolver from what Jeff has explained to me. The State resolver
is something is tuned into OSGi dependency conventions. The version
Jeff tried to put together for me came out of Equinox. Where all the
variants live I don't know. I'll go to Ottawa one of these days and
just find out! :-)

> and of course the PDE is doing so...so I don't think it's
> 'internal' API (although it could be).  Would unification in
> practice mean putting this code in a single API/package/bundle?  Or
> is there something else about this that I'm missing?

I think that's what Jeff is talking about.

>
> One point though...since Equinox is an implementation of OSGi, and
> Eclipse plugins and features have meta-information *beyond* what
> OSGi defines by spec, I imagine that there has to be at least a
> bundle-level separation between (e.g.) bundle dependency info in
> manifest.mf...which is read/used by the Equinox platform, and
> feature-level dependency info (in feature.xml) that is read/used by
> the PDE.

I would imagine this is accounted for because the code I saw came
from Equinox. Not sure if there is any distinction between OSGi-ness
and Eclipse-ness in there. But it would be useful as I would like to
account for straight-up OSGi development that is not Eclipse related.
People using IDEA or Netbeans might be doing OSGi work.

>
> If there is a description of what you mean by 'unify state resolver
> code' then please let me know where it is and I'll examine.

If you're going to talk to Jeff I'm sure he can explain where all
this stuff lives in Eclipse-land how best it would tied together for
external use for something like Maven. I just know what it's supposed
to do, not the mechanics of how folks in Eclipse-land would all use
the same code in addition to giving clients a single package to use.

Jason.



This message (1) on pde-build-dev contains the state resolver as an
attachment. I used this to calculate access rules for the JDT
compiler, and to generate POMs for bundles.

http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00262.html


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


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

Re: The Future of the Release Process.

[Tom Huybrechts]

   6) All source files in the sources.jar files will contain the following
  header.
  ---(snip)---
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  "License"); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
  ---(snip)---



Ditto for the pom itself ?

Tom

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

Re: downloading eclipse runtime binary or RCP delta pack

[Tom Huybrechts]

On 12/18/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:

>
> Graham,
>
>
> On Monday 18 December 2006 04:26, Graham Leggett wrote:
>>> For compilation purpose the win32 eclipse jars are availabe in
>>> maven (
>>> repo1.maven.org), so compilation is not a problem.
>>
>> The eclipse jars in repo1.maven.org are over a year old, and only
>> a small
>> subset of the eclipse jars are available. It's far safer in the
>> long term
>> to create a complete and up to date repo of your own.
>
> The problem is that the project Bhupendra is talking about is an
> open source
> project with developers from SEVERAL companies scattered all over
> the place,
> several of which don't have their own internal maven repositories
> setup.
> Thus, requiring this basically would require each developer to do this
> themselves which the whole point of maven's dependency management
> stuff was
> to avoid all that.
>
> My can't someone on the Maven team run the plugin/script and put
> them up on
> repo1 someplace?   That's what I'm having a hard time
> understanding.   People
> obviously want them published, what stopping them from being
> published?
>

Seems like a good idea to me.

Jason.


We'd better have the POMs right the first time with regards to
dependencies, because they cannot be updated.

Tom





>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727C: 508-380-7194
> [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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




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

Re: downloading eclipse runtime binary or RCP delta pack

[Tom Huybrechts]

On 12/18/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:

On 18 Dec 06, at 10:23 AM 18 Dec 06, Tom Huybrechts wrote:

> On 12/18/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>
>> On 18 Dec 06, at 9:59 AM 18 Dec 06, Daniel Kulp wrote:
>>
>> >
>> > Graham,
>> >
>> >
>> > On Monday 18 December 2006 04:26, Graham Leggett wrote:
>> >>> For compilation purpose the win32 eclipse jars are availabe in
>> >>> maven (
>> >>> repo1.maven.org), so compilation is not a problem.
>> >>
>> >> The eclipse jars in repo1.maven.org are over a year old, and only
>> >> a small
>> >> subset of the eclipse jars are available. It's far safer in the
>> >> long term
>> >> to create a complete and up to date repo of your own.
>> >
>> > The problem is that the project Bhupendra is talking about is an
>> > open source
>> > project with developers from SEVERAL companies scattered all over
>> > the place,
>> > several of which don't have their own internal maven repositories
>> > setup.
>> > Thus, requiring this basically would require each developer to
>> do this
>> > themselves which the whole point of maven's dependency management
>> > stuff was
>> > to avoid all that.
>> >
>> > My can't someone on the Maven team run the plugin/script and put
>> > them up on
>> > repo1 someplace?   That's what I'm having a hard time
>> > understanding.   People
>> > obviously want them published, what stopping them from being
>> > published?
>> >
>>
>> Seems like a good idea to me.
>>
>> Jason.
>
> We'd better have the POMs right the first time with regards to
> dependencies, because they cannot be updated.
>

We can put them in a staging repository for people to use for a while
and let people evaluate them. Fix over the course of a few weeks and
let release them into the wild.

Jason.



They have been in http://repo1.maven.org/eclipse for a while




> Tom
>
>
>
>>
>> >
>> > --
>> > J. Daniel Kulp
>> > Principal Engineer
>> > IONA
>> > P: 781-902-8727C: 508-380-7194
>> > [EMAIL PROTECTED]
>> >
>> >
>> -
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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




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

Re: downloading eclipse runtime binary or RCP delta pack

[Tom Huybrechts]

On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

"Graham Leggett" <[EMAIL PROTECTED]> schrieb am 18.12.2006 17:53:54:

> The problem I saw posted recently about this was that once published,
the
> repository is cast in stone, including errors.

=8*O I beg your pardon? I looked in JIRA but couldn't find a report about
this. Is there? If not, I'd open one. ;-)

The idea that you'll never have to fix a broken POM/JAR/whatever is just
ridiculous. :-) As I understand it, the repo admins are just very
reluctant to modify already published artefacts.



The repository IS cast in stone. Deployed POMs are not updated since
clients do not expect them to change and will not check for updates
(nor should they). This is an integral part of build reproducibility.

The only way to fix a broken artifact is by uploading a new version.

Tom


Regards,

--
Aaron Digulla


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




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

Re: downloading eclipse runtime binary or RCP delta pack

[Tom Huybrechts]

On 12/19/06, Graham Leggett <[EMAIL PROTECTED]> wrote:

On Tue, December 19, 2006 10:24 am, [EMAIL PROTECTED] wrote:

> =8*O I beg your pardon? I looked in JIRA but couldn't find a report about
> this. Is there? If not, I'd open one. ;-)
>
> The idea that you'll never have to fix a broken POM/JAR/whatever is just
> ridiculous. :-) As I understand it, the repo admins are just very
> reluctant to modify already published artefacts.

That's what I meant, yes.

As it turns out, someone has already published the full eclipse tree to
repo1, so all this is moot :)



No it's not - the Eclipse artifacts are published to a separate
repository and are not yet integrated into the main repository.


Regards,
Graham
--



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




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

Re: versioning

[Tom Huybrechts]

From the spec:


A version string is a series of positive numbers separated by periods.
The numbers are compared component by component from left to right. If
any number is greater than the corresponding number of the supplied
string the method returns true. If the number is less than it returns
false. If the corresponding numbers are equal the next number is
examined.

That shouldn't be a problem...


On 12/19/06, ir. ing. Jan Dockx <[EMAIL PROTECTED]> wrote:

I believe that Maven version number support should at least make it
possible to apply the specification / implementation version
numbering scheme that is part of the Java standard ().




On 19 Dec 2006, at 9:33, [EMAIL PROTECTED] wrote:

> Jason Dillon <[EMAIL PROTECTED]> schrieb am 19.12.2006 01:26:54:
>
>> I've seen projects switch back and forth... depends on who is in
>> power at the time and what style they like.  So it would be best if
>> mvn would be able comprehend:
>
> Since versions are such an important information in Maven, Maven
> should
> refuse version numbers which aren't easily comparable.
>
> How about forcing the contents of the version element in the POM to
> 1-3
> digits, separated by dots? That would "help" people who can't decide.
>
> After that, you can add something with "-" which maven will just
> string-compare (so alpha10 comes between alpha1 and alpha2).
>
> Regards,
>
> --
> Aaron Digulla
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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




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

Re: The Future of the Release Process.

[Tom Huybrechts]

On 12/19/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

Hello Joakim,

I like this discussion, I am a big fan of automating the release
process.

I also have some hands on experience being RM for Ant 1.6 and 1.7.

For Ant 1.7, we are using what you call the staged release process.

When I prepare a build, I have to assume that the vote on the
binaries will be positive and prepare everything with a release
version in mind.

Tagging the release should to my opinion happen between preparing and
staging the release.

To make sure everything is clean, the SVN sandbox could be recreated
based on the tag.

When I did my first build of ANT 1.7.0 last week, someone checked
code in between the time when I created my SVN sandbox and the time
when I created my tag.
In the end, this change was included in the tag but not in my build.
Bad ...  See [1] the command used to create the tag



This cannot happen if you make a tag based from your local working
copy instead of trunk
The release plugin already does this.

http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html

tom


Also, creating a branch for a release is optional. Right now we are
releasing Ant 1.7.0 from the trunk, and we
do not have a ANT_17_BRANCH.

Suggested modifications for your staged release process :

 c) 'prepare' release (occurs once)
   * Create a branch using provided Branch ID for this release.
   * Update poms in branch to provided Release Version ID.
+* Optionally update documentation in branch to provided
Release Version ID.
   * Update poms in trunk to provided Next Development
Version ID.

  +  d) tag the release (occurs 1 or more times)

  +  e) create a new SVN sandbox using the tag created in d)

  -  d) stage release (occurs 1 or more times)
  +  f) 'stage' release (occurs 1 or more times)


It would be cool if you could persist your ideas concerning the
release process to a document in SVN or to a Wiki page.

Regards,

Antoine


[1]
svn copy https://svn.apache.org/repos/asf/ant/core/trunk \
 https://svn.apache.org/repos/asf/ant/core/tags/ANT_170 \
 -m "Tagging version 1.7.0 of Ant"

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




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

Re: ApacheCon Talks

[Tom Huybrechts]

On 12/19/06, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

Jason van Zyl wrote:
>
> On 19 Dec 06, at 12:28 PM 19 Dec 06, Steve Loughran wrote:
>
>> Jason van Zyl wrote:
>>> Hi,
>>> Just checking in with folks to see if anyone is planning ApacheCon
>>> talks.
>>
>> 1. "fear the repository police". We will pick people in the audience
>> and beat them with rolled up copies of the pom schema until they
>> promise not to publish invalid metadata. we will start off with "Is
>> there anyone here who works on commons-logging?",
>>
>
> It will soon be impossible to publish invalid metadata.

Speaking as someone who also works on commons-logging (*ducking*), is
there work being done on a maven-repo-compliant-plugin or something
similar that could be run on every pom that is submitted through
MAVENUPLOAD? I.e. confirming to the rules set up here:
   http://maven.apache.org/guides/mini/guide-ibiblio-upload.html

If not, I think I could put something together.


I have some play-stuff in the maven-repositorytools-plugin
(mojo-sandbox) as part of a bundle-deploy mojo. It includes iterating
over imports to see if they are provided by a dependency, and also
some POM element checking.

tom



>> 2. Something on big project ant; ivy, import &c. Mostly how to use
>> these concepts effectively and so have a scaled build that doesnt
>> force you to throw away all your existing build process.
>
> Interesting as one of my topics in the Maven Enterprise BOF is the
> conversion of huge project that basically retained 95% of it's Ant
> scripting, except it is packaged up in Maven plugins to be maintainable,
> and understandable.
>
>> 3. Work related: something on virtualization; how to use amazon EC2 to
>> host apache httpd and the like, what works, what doesn't (persistence,
>> mainly). We'd use smartfrog to manage the deployments and maybe show
>> using linuxcoe/instalinux to create the amazon Xen image at build time
>> based on the RPM list you have under SCM.
>>
>> 4. I've invited the TestNG people and Xavier of Ivy fame to submit
>> proposals. Both would be good. BTW, there's lots of unhappiness in
>> TestNG-users about SureFire; someone should talk to them about their
>> needs.
>>
>
> Kenney is working on the surefire plugin as we speak.
>
>> -Steve
>>


--
Dennis Lundberg

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




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

Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.

[Tom Huybrechts]

On 12/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 12/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>
> On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > >
> > > If I understand correctly, the problem is that a 'staged' release
> > > still contains a SNAPSHOT keyword in the metadata/filename?
> >
> > Yes, that's the problem.
>
> I would agree, but that's not how I understand staging to work at all.
>
> The Apache projects I work on like to vote on the *exact* artifacts
> that will be released to the public, so the staged release must not
> have a -SNAPSHOT qualifier.


Agreed.  When I vote on a release, I'm always saying "show me the bits."

In this scenario, it would be nice for the release plugin to have an option
to copy approved artifacts from the staging area to the release area (along
with corresponding signatures and metadata updates) *without* any
modification to the artifacts themselves.



I wrote the repositorytools plugin in mojo-sandbox for this reason. It
has goals to copy a specific artifact (including signatures) or an
entire remote repository to another repository, while merging the
necessary repository metadata.

This is still work-in-progress although Jason already tested it (I
think it was on a Geronimo release ).

Tom


--
> Wendy


Craig




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

Re: Who should use SNAPSHOT when? RE: The Future of the Release Process.

[Tom Huybrechts]

On 1/2/07, Dan Fabulich <[EMAIL PROTECTED]> wrote:


Wendy Smoak wrote:
> On 12/22/06, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> > > From: Kenney Westerhof [mailto:[EMAIL PROTECTED]
> > >
> > > If I understand correctly, the problem is that a 'staged' release
> > > still contains a SNAPSHOT keyword in the metadata/filename?
> >
> > Yes, that's the problem.
>
> I would agree, but that's not how I understand staging to work at all.
>
> The Apache projects I work on like to vote on the *exact* artifacts
> that will be released to the public, so the staged release must not
> have a -SNAPSHOT qualifier.

I realize now that I agreed with Kenney too soon.  The problem is,
really, the existence of a -SNAPSHOT qualifier at all, which, in turn,
forces us to jump through hoops at the last second in the release
process in order to remove that qualifier.  (-SNAPSHOT has some
advantages, but for many organizations, the disadvantages are
considerably more significant.)

The real point here is that the "staging" process (which creates
non-SNAPSHOT binaries that have not yet been released) should be
something that we could use throughout the development cycle, not some
special last-minute thing that provides special last-minute binaries.
The way to do that is to provide build numbers on non-SNAPSHOT releases,
allowing us to bless a release binary without modifying it (for example,
by moving it from one repository to another).



That's essentially what Eclipse does... While developing to a 3.3
release, each bundle in every build gets a version qualifier (e.g.
3.3.0.v20061116) which is incremented if the bundle changes.

The eventual 3.3 release will then just be a collection of bundles
with the latest qualifier for each.
As an example, these are some off the bundles in the 3.2.1 release.
Note that some bundles that never changed still have the 3.2.0.v
version.

org.eclipse.core.boot_3.1.100.v20060603.jar
org.eclipse.core.commands_3.2.0.I20060605-1400.jar
org.eclipse.core.contenttype_3.2.0.v20060603.jar
org.eclipse.core.expressions_3.2.1.r321_v20060721.jar
org.eclipse.core.filebuffers_3.2.1.r321_v20060721.jar
org.eclipse.core.filesystem.win32.x86_1.0.0.v20060603.jar
org.eclipse.core.filesystem_1.0.0.v20060603.jar
org.eclipse.core.jobs_3.2.0.v20060603.jar
org.eclipse.core.resources.compatibility_3.2.0.v20060603.jar
org.eclipse.core.resources.win32_3.2.0.v20060603.jar
org.eclipse.core.resources_3.2.1.R32x_v20060914.jar
org.eclipse.core.runtime.compatibility.auth_3.2.0.v20060601.jar
org.eclipse.core.runtime.compatibility.registry_3.2.1.R32x_v20060907
org.eclipse.core.runtime.compatibility_3.1.100.v20060603.jar
org.eclipse.core.runtime_3.2.0.v20060603.jar
org.eclipse.core.variables_3.1.100.v20060605.jar

More info at http://wiki.eclipse.org/index.php/Version_Numbering

Tom


-Dan
___
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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

status of MSUREFIRE-31, MSUREFIRE-84 (junit4 support)

[Tom Huybrechts]

Hi all,

I was wondering if anyone is working on junit4 support ? If not, is
this because of a lack of time or interest or is something blocking it
?

Tom

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

deploy surefire snapshot

[Tom Huybrechts]

Hi,

Could somebody deploy a surefire snapshot (including the
surefire-junit4 provider) ?

thanks,

Tom

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

Re: calling vote for 2.0.5

[Tom Huybrechts]

Can't you "solve" this with -Dhttps.proxyHost=xxx -Dhttps.proxyPort=... ?

On 1/11/07, Franz Fehringer <[EMAIL PROTECTED]> wrote:

Will this release contain solutions to

MNG-2305
MNG-2066
WAGONHTTP-6

?

These issues mean, that it is impossible to access HTTPS (SSL)
repositories from behind proxies/firewalls (i.e. from corporate networks).

Thanks and greetings

Franz


Jason van Zyl schrieb:
> Hi,
>
> I want to call a vote for 2.0.5. All the issues that are going to get
> done are done. We'll release and move on.
>
> I would like to start building all releases from a standard machine
> with the same JDK. I would like to propose the maven.org machine which
> is monitored 24/7 running Linux. It serves as the central repository
> but can easily handle a few builds. They can be built from that
> machine and deployed to Apache. I think this is far better then each
> of us building stuff from our own machines and deploying.
>
> Otherwise everything for 2.0.5 is ready to go.
>
> I will also chop up what's in JIRA into some smaller versions as I
> think some micro releases for improvements and smaller changes is
> better then waiting 7 months for another release. If we schedule them
> out them people can decide whether they want to upgrade or not. But I
> know there are several things I would like to get in and I know that
> Mike/Ralph would like to get in MNG-1577 which we can squeeze into a
> 2.0.6 in a week or two. These are micro release.
>
> Jason.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>




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




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

Re: [VOTE] Release Maven 2.0.5

[Tom Huybrechts]

2) The repository copying only works using the file:/// when you're
on the same machine due to a bug in Wagon.


It should also work for http if you have the latest wagon api  Did you
try that ?

Tom

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

Re: [surefire] Adding providers

[Tom Huybrechts]

You're right - it is hardcoded. See http://jira.codehaus.org/browse/SUREFIRE-141

Tom

On 2/6/07, Arnaud Bailly <[EMAIL PROTECTED]> wrote:

Hi to all,
I wish to extend maven-surefire with a new provider. As far as I can
tell from the plugin's source code, this is not possible without
modification of the plugin's code as providers are hardcoded in the
constructSurefireBooter() method. BTW, this explains
http://jira.codehaus.org/browse/SUREFIRE-169 : testNg always
supersedes junit.

Am I missing something or is there any plan to allow for a more open
provider API ?

Regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com


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




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

Re: Fix for resolve source in the dependency plugin

[Tom Huybrechts]

Yves,

At http://jira.codehaus.org/browse/MDEP you can look at the existing
issues with this plugin. It's possible that is issue is already
reported or even solved. If not, you can create an issue and/or attach
the patch.

Tom

On 2/20/07, gc134728 <[EMAIL PROTECTED]> wrote:

Dear maven developers,

I recently wanted to use the dependency plugin to download the sources but
when executing it didn't seem to do much.  So I download the code from the
maven repo and looked at the problem. It didn't seem to be fully implemented.

I now created a patch for this.  Could someone forward it to brainf or one the
developers working on this plugin.  I tried to follow the design ideas by it's
creater.

I left 2 items open (check todo tags):
1) implementation of the markers file
2) use of the groupid check (don't know why this should occur)

If he wants I can further implement these items to.

the patch was created on the 506840 revision.

Greetz,
Y. Van Steen
---
Scarlet One Unlimited
Free national calls, surf up to 6 Mbit/s, 50 GB download volume
For only EUR 49,95 per month. No Belgacom subscription needed.  All in!
http://www.scarlet.be
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




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

Re: Surefire Release

[Tom Huybrechts]

I'm using it in production without issues.

One thing that could be improved is that the junit4 provider now looks
at the filename to find tests, instead of looking for @Test
annotations.

Tom

On 2/22/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 22 Feb 07, at 5:00 PM 22 Feb 07, Brett Porter wrote:

> Good idea.
>
> Does anyone know if the junit4 support is 'production ready'?
>

I think if anyone can find Tom he's been using it as he made the
initial patches but have not used it myself.

jason.

> - Brett
>
> On 23/02/2007, at 3:39 AM, Jason van Zyl wrote:
>
>> Hey Brett,
>>
>> If you are going to do a push for TestNG do you think you might be
>> able to push out a release to get the 20 or so issues out into the
>> wild before digging in?
>>
>> Thanks,
>>
>> Jason.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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




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

Re: [VOTE] Release Maven 2.0.7

[Tom Huybrechts]

(non-binding) +1

On 6/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

The release notes are here:

http://jira.codehaus.org/secure/ReleaseNote.jspa?
projectId=10500&styleName=Html&version=13138

The tag is here:

http://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.7/

Staging repository:

http://people.apache.org/~jvanzyl/maven-2.0.7-staging-repository/

And the distros you are interested in are here:

http://people.apache.org/~jvanzyl/maven-2.0.7/

Thanks,

Jason.



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



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




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

result code for mvn.bat on windows broken

[Tom Huybrechts]

Hi,

can anybody confirm/deny that the changes to mvn.bat in r543625 have
broken result codes ?
Errors are no longer reported in 2.0.7.

If I restore the @endLocal, it works as it did before.

:error
+if "%OS%"=="Windows_NT" @endlocal
set ERROR_CODE=1


Tom

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

Re: [PLEASE TEST] Maven 2.0.10-RC6

[Tom Huybrechts]

My results are different.

2.0.8 vs 2.0.9-RC6
50 module project, clean install: 6m2s vs 8m53s
50 module project, install: 3m10s vs 4m51s

5 module project, clean install: 48s vs 1m2s
5 module project, install: 20s vs 28s

Memory consumption was not significantly different.

That's a 30-50% performance hit :(

Tom

On Sat, Aug 9, 2008 at 11:53 AM, Mauro Talevi
<[EMAIL PROTECTED]> wrote:
> No problems encountered.  WRT timing/memory, it now actually seems to have
> improved somewhat.
>
> Eg on 50-ish module build:
> 2.0.9
> [INFO] Total time: 7 minutes 24 seconds
> [INFO] Finished at: Sat Aug 09 10:25:18 BST 2008
> [INFO] Final Memory: 76M/154M
>
> 2.0.10-RC6
> [INFO] Total time: 6 minutes 20 seconds
> [INFO] Finished at: Sat Aug 09 10:41:52 BST 2008
> [INFO] Final Memory: 70M/142M
>
> Thanks!
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Improving CI & ITs

[Tom Huybrechts]

On Tue, Dec 16, 2008 at 1:51 AM, Jason van Zyl  wrote:
> Howdy,
>
> This is primarily directed at Benjamin (who has done a great job getting the
> ITs in shape), John (who has spent a great deal of time getting our grid up
> and running), and Tom (who has made some very cool additions to Hudson which
> we will leverage for Maven).
>
> Today we started being able to build Maven 3.x across the grid but now it's
> time to get serious about doing some layering for speed and completeness.
>
> Tom has some very cool additions to Hudson that allow us to write plugins in
> Hudson as Plexus components and one of the first plugins Tom has written is
> a way to propagate a successful bootstrap of Maven across a set of projects.
> This plugin combined with the greatly improved ITs for the core and the
> fleshing out of the ITs for all the core plugins will allow us to really
> start hammering down on 3.x.
>
> 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. Once we pick a
> work flow we can probably write any plugins we need. We can also start
> selectively taking any useful components from Continuum as they should now
> work in Hudson. The Plexus integration was checked into Hudson about a month
> ago by Tom.
>
> 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.

Actually what was checked in to Hudson is a way to plug into the
plugin mechanism itself. The Plexus integration is a possible
implementation of that, but is not publicly available.

The Hudson plugin for maven integration testing that I wrote is not
based on the Plexus integration.
It provides two things:
- a build trigger that monitors for the availability of a new Maven
version (e.g. a new snapshot or new RC)
- a Maven builder that downloads and installs the Maven version prior
to running a build
Important to note is that this will work too for a Maven that is built
on another (remote) Hudson.
So anyone could configure it to track nightly builds or release
candidates, and continously build their own projects using the latest
Maven version.
And of course it can be used too to build the maven ITs themselves.

There's still a little work to do.
- For starters it currently depends on having the Maven build as an
archived artifact in Hudson, but perhaps it's more desirable to get
them from a Maven repository ?
- There should be a clear way to identify which Maven version was used
- It's not threadsafe yet, so multiple concurrent builds with the same
builder would definitely go wrong.

Tom

>
> 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.
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
>  -- Jacques Ellul, The Technological Society
>
>
> -
> 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: Programmatically adding dependencies to a MavenProject

[Tom Huybrechts]

On Mon, Jan 26, 2009 at 9:23 PM, Maarten Storm  wrote:
> Yes it is a bad idea to add add dependencies programatically, I had a
> RTFM thing :-( . The Pom must be the project model in all cases. Oeps
> and sorry for that. I fixed the issue by using the scope import stated
> somewhere in the conversation. Maybe a stupid question when will Maven
> 3 be released?
>
> Kind regards,
> Maarten Storm
>

Maven 3 will be released somewhere between january and december. The
exact year is not known yet ;)

Tom

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