You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mirko Friedenhagen <mf...@gmail.com> on 2014/02/05 22:05:43 UTC
reactorProjects vs. session.getProjects() Was: Re: Adding a classpath
element within a Mojo
Hello,
just for my understanding:
- Does the property reactorProjects[0] hold the projects in reactor build order?
Regards Mirko
[0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68
On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> Maven first calls #afterProjectsRead(MavenSession), then calculates
> reactor build order. So session.getProjects() still returns unsorted
> project list during afterProjectsRead, which most likely does not matter
> in your case.
>
> --
> Regards,
> Igor
>
>
> On 2/4/2014, 17:47, William Ferguson wrote:
>>
>> Can you explain the need to establish the reactor build order? I had
>> expected session.getProjects() to have returned modules in the order they
>> are defined. Are you saying that is not the case and that it would need to
>> be configured by the LifeCycleParticipant?
>>
>> I think I can make the hack work. So I'll go with that for now. But I'd
>> like to be able to annotate that with an issue number if there are plans
>> to
>> enhance the API on this front so that we know what and when to replace.
>>
>> I'd love to help enhance Maven (I have plenty to pay back for the hours it
>> has saved me over the years) but I don't have the band width right now and
>> I also don't feel like I have a good enough understanding of the Maven
>> core. But as I said before if you think this is a worthwhile enterprise
>> then help me create an issue that spells out what you think needs doing
>> and
>> I'll try to get back to it in a couple of months.
>>
>> William
>>
>>
>>
>> On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <ig...@ifedorenko.com>
>> wrote:
>>
>>>
>>> On 2/4/2014, 1:06, William Ferguson wrote:
>>>
>>>> OK, I'm getting the dependencies to resolve and I can amend the
>>>> classpath,
>>>> but I think I've hit a road block for multi module builds.
>>>>
>>>> LifeCycleParticipant is only ever called once at the root. This means
>>>> that
>>>> if I have a project with 2 modules where ModuleB depends on ModuleA then
>>>> I'm not going to be able extract and add ModuleA and it's classes when
>>>> the
>>>> LifeCycleParticipant executes because ModuleA will not have been built
>>>> yet.
>>>>
>>>> Is there some way to get the LifeCycleParticipant called for every
>>>> module
>>>> of the build?
>>>>
>>>>
>>> Looks like there are two related but distinct concerns there.
>>>
>>> First, it is necessary to establish reactor build order. This must
>>> happen before actual build starts and lifecycle participant provides a
>>> way to do this.
>>>
>>> Second, it is necessary to resolve dependencies among reactor modules.
>>> This has to happen as part of the build itself and I don't think there
>>> is an API for that yet.
>>>
>>> One hack-ish way to workaround this is to resolve reactor dependencies
>>> is to create empty directories from lifecycle participant,
>>> ModuleA/target/something in your case, and make sure ModuleA's build
>>> populates the directory with expected files.
>>>
>>> Proper solution requires changes to maven core. I can provide some
>>> pointers if you want to try this.
>>>
>>> --
>>> Regards,
>>> Igor
>>>
>>>
>>> William
>>>>
>>>>
>>>> William
>>>>
>>>>
>>>> On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson <
>>>> william.ferguson@xandar.com.au> wrote:
>>>>
>>>> Igor,
>>>>>
>>>>>
>>>>> I've worked out how to modify the project classpath (pretty trivial).
>>>>> But
>>>>> I'm struggling to get the project dependencies resolved during
>>>>> LifeCycleParticipant#afterProjectsRead.
>>>>>
>>>>> I tried using the TychoDependencyResolver to #setupProject and
>>>>> #resolveProject but that isn't causing the projects dependencies to get
>>>>> resolved. I'm not sure what I'm missing.
>>>>>
>>>>> I've created a cut down project dep-resolution-plugin at
>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin.git
>>>>> And a project that tests that plugin at
>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin-test.git
>>>>> If you could have a look and point out what it is I'm missing I'd be
>>>>> most
>>>>> grateful.
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson <
>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>
>>>>> Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1 too.
>>>>>>
>>>>>>
>>>>>> I'll trying switching to the annotations. Javadoc annotations were
>>>>>> just
>>>>>> for conformity with the rest of the project.
>>>>>>
>>>>>> If that doesn't work, I'll put together a cut down example.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> William
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <igor@ifedorenko.com
>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> No, no tricks, as far as I know Plexus (and now Sisu/Guice) only
>>>>>> inject
>>>>>>>
>>>>>>> fully configured components. so the behaviour you describe is rather
>>>>>>> odd.
>>>>>>>
>>>>>>> What version of Maven do you use? Is it official distribution from
>>>>>>> Apache or something you built locally?
>>>>>>>
>>>>>>> Not likely related, but I haven't used javadoc plexus annotations in
>>>>>>> ages. Any particular reason you don't want to use java 5 @Component?
>>>>>>>
>>>>>>> In any case, if you can provide small standalone example that shows
>>>>>>> the
>>>>>>> problem, I can try to see what's going on there.
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>>
>>>>>>>
>>>>>>> On 1/23/2014, 0:54, William Ferguson wrote:
>>>>>>>
>>>>>>> Igor,
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm having some difficulty getting the LifecycleParticipant to
>>>>>>>> resolve
>>>>>>>> Maven components.
>>>>>>>>
>>>>>>>> In particular, the org.apache.maven.project.
>>>>>>>> ProjectDependenciesResolver.
>>>>>>>> While it gets resolved, none of it's internal attributes get
>>>>>>>> resolved.
>>>>>>>> So
>>>>>>>> calls to projectDependenciesResolver.resolve crash with NPEs because
>>>>>>>> DefaultProjectDependenciesResolver#logger or #repoSystem is not
>>>>>>>> initialised.
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * @component
>>>>>>>> * @readonly
>>>>>>>> * @required
>>>>>>>> */
>>>>>>>> protected ProjectDependenciesResolver
>>>>>>>> projectDependenciesResolver;
>>>>>>>>
>>>>>>>> Is there some special trick to getting components fully initialised
>>>>>>>> in a
>>>>>>>> LifecycleParticipant?
>>>>>>>>
>>>>>>>> William
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko
>>>>>>>> <igor@ifedorenko.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>> Here is Tycho lifecycle participant [1] and here is the code that
>>>>>>>>
>>>>>>>>> injects new dependencies in MavenProject instances [2].
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>> TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
>>>>>>>>> [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>> MavenDependencyInjector.java?h=tycho-0.19.x
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards,
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/20/2014, 8:21, William Ferguson wrote:
>>>>>>>>>
>>>>>>>>> Thanks Igor,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> could you give me a link to an example or some code that
>>>>>>>>>>
>>>>>>>>>> - Utilises AbstractMavenLifecycleParticip
>>>>>>>>>> ant#afterProjectsRead
>>>>>>>>>> - How to manipulate the project <dependencies> from there.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I found an example example by Brett Porter, but the doco is pretty
>>>>>>>>>> thin
>>>>>>>>>> and
>>>>>>>>>> I can't see how I would go about inject extra elements into the
>>>>>>>>>> classpath
>>>>>>>>>> from there.
>>>>>>>>>>
>>>>>>>>>> William
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko <
>>>>>>>>>> igor@ifedorenko.com
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> There is probably more ways to do this, but you can implement
>>>>>>>>>>
>>>>>>>>>> AbstractMavenLifecycleParticipant#afterProjectsRead to
>>>>>>>>>> manipulate
>>>>>>>>>>>
>>>>>>>>>>> project <dependencies>. This is what we do in Tycho, where we
>>>>>>>>>>> resolve
>>>>>>>>>>> project OSGi dependencies in AbstractMavenLifecycleParticipant
>>>>>>>>>>> and
>>>>>>>>>>> then
>>>>>>>>>>> inject that into Maven project model as system scoped maven
>>>>>>>>>>> dependencies.
>>>>>>>>>>>
>>>>>>>>>>> I also think your usecase highlights general deficiency with
>>>>>>>>>>> current
>>>>>>>>>>> dependency model. Since you have to add classpath elements
>>>>>>>>>>> dynamically,
>>>>>>>>>>> these elements are not visible to maven-based tools like m2e
>>>>>>>>>>> without
>>>>>>>>>>> additional effort on the tools part. I think it will be useful to
>>>>>>>>>>> extend
>>>>>>>>>>> <dependency> element syntax to allow references for nested
>>>>>>>>>>> archive entries, i.e. "dependency on classes jar nested within
>>>>>>>>>>> this
>>>>>>>>>>> AAR
>>>>>>>>>>> archive".
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Regards,
>>>>>>>>>>> Igor
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/20/2014, 7:00, William Ferguson wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I realise this question isn't exactly related to dev within the
>>>>>>>>>>>> Maven
>>>>>>>>>>>> components, but it is about developing a Mojo using components
>>>>>>>>>>>> that
>>>>>>>>>>>> have
>>>>>>>>>>>> to
>>>>>>>>>>>> be pretty central and don't appear to be obviously documented
>>>>>>>>>>>> anywhere.
>>>>>>>>>>>> And
>>>>>>>>>>>> I ahve asked on maven-users without much luck.
>>>>>>>>>>>>
>>>>>>>>>>>> As part of the android-maven-plugin we have a Mojo which needs
>>>>>>>>>>>> to
>>>>>>>>>>>> add an
>>>>>>>>>>>> element to the compile time classpath for future Mojos
>>>>>>>>>>>> (specifically the
>>>>>>>>>>>> maven-compiler-plugin).
>>>>>>>>>>>>
>>>>>>>>>>>> Project has dependencies on artifacts of type AAR (Android
>>>>>>>>>>>> archive
>>>>>>>>>>>> - an
>>>>>>>>>>>> archive that contains several sub-artifacts including a classes
>>>>>>>>>>>> jar).
>>>>>>>>>>>>
>>>>>>>>>>>> Our Mojo unpacks the AAR artifacts and makes the sub-artifacts
>>>>>>>>>>>> available
>>>>>>>>>>>> to
>>>>>>>>>>>> other build components.
>>>>>>>>>>>>
>>>>>>>>>>>> One of those build components is the maven-compiler-plugin. We
>>>>>>>>>>>> want
>>>>>>>>>>>> to
>>>>>>>>>>>> add
>>>>>>>>>>>> the classes contained in the AAR dependencies to the compile
>>>>>>>>>>>> classpath
>>>>>>>>>>>> so
>>>>>>>>>>>> that the maven-compiler-plugin can compile our classes against
>>>>>>>>>>>> the
>>>>>>>>>>>> classes
>>>>>>>>>>>> from the AARs.
>>>>>>>>>>>>
>>>>>>>>>>>> How do we do that?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> William
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> ---------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: reactorProjects vs. session.getProjects() Was: Re: Adding a classpath
element within a Mojo
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Mirko,
> just for my understanding:
> - Does the property reactorProjects[0] hold the projects in reactor build order?
>
> Regards Mirko
> [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68
As far as i know the following gives you the correct order:
ProjectDependencyGraph projectDependencyGraph =
mavenSession.getProjectDependencyGraph();
List<MavenProject> sortedProjects =
projectDependencyGraph.getSortedProjects();
Kind regards
Karl Heinz Marbaise
>
> On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>> Maven first calls #afterProjectsRead(MavenSession), then calculates
>> reactor build order. So session.getProjects() still returns unsorted
>> project list during afterProjectsRead, which most likely does not matter
>> in your case.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2/4/2014, 17:47, William Ferguson wrote:
>>>
>>> Can you explain the need to establish the reactor build order? I had
>>> expected session.getProjects() to have returned modules in the order they
>>> are defined. Are you saying that is not the case and that it would need to
>>> be configured by the LifeCycleParticipant?
>>>
>>> I think I can make the hack work. So I'll go with that for now. But I'd
>>> like to be able to annotate that with an issue number if there are plans
>>> to
>>> enhance the API on this front so that we know what and when to replace.
>>>
>>> I'd love to help enhance Maven (I have plenty to pay back for the hours it
>>> has saved me over the years) but I don't have the band width right now and
>>> I also don't feel like I have a good enough understanding of the Maven
>>> core. But as I said before if you think this is a worthwhile enterprise
>>> then help me create an issue that spells out what you think needs doing
>>> and
>>> I'll try to get back to it in a couple of months.
>>>
>>> William
>>>
>>>
>>>
>>> On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>>
>>>>
>>>> On 2/4/2014, 1:06, William Ferguson wrote:
>>>>
>>>>> OK, I'm getting the dependencies to resolve and I can amend the
>>>>> classpath,
>>>>> but I think I've hit a road block for multi module builds.
>>>>>
>>>>> LifeCycleParticipant is only ever called once at the root. This means
>>>>> that
>>>>> if I have a project with 2 modules where ModuleB depends on ModuleA then
>>>>> I'm not going to be able extract and add ModuleA and it's classes when
>>>>> the
>>>>> LifeCycleParticipant executes because ModuleA will not have been built
>>>>> yet.
>>>>>
>>>>> Is there some way to get the LifeCycleParticipant called for every
>>>>> module
>>>>> of the build?
>>>>>
>>>>>
>>>> Looks like there are two related but distinct concerns there.
>>>>
>>>> First, it is necessary to establish reactor build order. This must
>>>> happen before actual build starts and lifecycle participant provides a
>>>> way to do this.
>>>>
>>>> Second, it is necessary to resolve dependencies among reactor modules.
>>>> This has to happen as part of the build itself and I don't think there
>>>> is an API for that yet.
>>>>
>>>> One hack-ish way to workaround this is to resolve reactor dependencies
>>>> is to create empty directories from lifecycle participant,
>>>> ModuleA/target/something in your case, and make sure ModuleA's build
>>>> populates the directory with expected files.
>>>>
>>>> Proper solution requires changes to maven core. I can provide some
>>>> pointers if you want to try this.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> William
>>>>>
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>> On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson <
>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>
>>>>> Igor,
>>>>>>
>>>>>>
>>>>>> I've worked out how to modify the project classpath (pretty trivial).
>>>>>> But
>>>>>> I'm struggling to get the project dependencies resolved during
>>>>>> LifeCycleParticipant#afterProjectsRead.
>>>>>>
>>>>>> I tried using the TychoDependencyResolver to #setupProject and
>>>>>> #resolveProject but that isn't causing the projects dependencies to get
>>>>>> resolved. I'm not sure what I'm missing.
>>>>>>
>>>>>> I've created a cut down project dep-resolution-plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin.git
>>>>>> And a project that tests that plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin-test.git
>>>>>> If you could have a look and point out what it is I'm missing I'd be
>>>>>> most
>>>>>> grateful.
>>>>>>
>>>>>> William
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson <
>>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>>
>>>>>> Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1 too.
>>>>>>>
>>>>>>>
>>>>>>> I'll trying switching to the annotations. Javadoc annotations were
>>>>>>> just
>>>>>>> for conformity with the rest of the project.
>>>>>>>
>>>>>>> If that doesn't work, I'll put together a cut down example.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> William
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <igor@ifedorenko.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> No, no tricks, as far as I know Plexus (and now Sisu/Guice) only
>>>>>>> inject
>>>>>>>>
>>>>>>>> fully configured components. so the behaviour you describe is rather
>>>>>>>> odd.
>>>>>>>>
>>>>>>>> What version of Maven do you use? Is it official distribution from
>>>>>>>> Apache or something you built locally?
>>>>>>>>
>>>>>>>> Not likely related, but I haven't used javadoc plexus annotations in
>>>>>>>> ages. Any particular reason you don't want to use java 5 @Component?
>>>>>>>>
>>>>>>>> In any case, if you can provide small standalone example that shows
>>>>>>>> the
>>>>>>>> problem, I can try to see what's going on there.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/23/2014, 0:54, William Ferguson wrote:
>>>>>>>>
>>>>>>>> Igor,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm having some difficulty getting the LifecycleParticipant to
>>>>>>>>> resolve
>>>>>>>>> Maven components.
>>>>>>>>>
>>>>>>>>> In particular, the org.apache.maven.project.
>>>>>>>>> ProjectDependenciesResolver.
>>>>>>>>> While it gets resolved, none of it's internal attributes get
>>>>>>>>> resolved.
>>>>>>>>> So
>>>>>>>>> calls to projectDependenciesResolver.resolve crash with NPEs because
>>>>>>>>> DefaultProjectDependenciesResolver#logger or #repoSystem is not
>>>>>>>>> initialised.
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @component
>>>>>>>>> * @readonly
>>>>>>>>> * @required
>>>>>>>>> */
>>>>>>>>> protected ProjectDependenciesResolver
>>>>>>>>> projectDependenciesResolver;
>>>>>>>>>
>>>>>>>>> Is there some special trick to getting components fully initialised
>>>>>>>>> in a
>>>>>>>>> LifecycleParticipant?
>>>>>>>>>
>>>>>>>>> William
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko
>>>>>>>>> <igor@ifedorenko.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is Tycho lifecycle participant [1] and here is the code that
>>>>>>>>>
>>>>>>>>>> injects new dependencies in MavenProject instances [2].
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>>> TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
>>>>>>>>>> [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>>> MavenDependencyInjector.java?h=tycho-0.19.x
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/20/2014, 8:21, William Ferguson wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks Igor,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> could you give me a link to an example or some code that
>>>>>>>>>>>
>>>>>>>>>>> - Utilises AbstractMavenLifecycleParticip
>>>>>>>>>>> ant#afterProjectsRead
>>>>>>>>>>> - How to manipulate the project <dependencies> from there.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I found an example example by Brett Porter, but the doco is pretty
>>>>>>>>>>> thin
>>>>>>>>>>> and
>>>>>>>>>>> I can't see how I would go about inject extra elements into the
>>>>>>>>>>> classpath
>>>>>>>>>>> from there.
>>>>>>>>>>>
>>>>>>>>>>> William
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko <
>>>>>>>>>>> igor@ifedorenko.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> There is probably more ways to do this, but you can implement
>>>>>>>>>>>
>>>>>>>>>>> AbstractMavenLifecycleParticipant#afterProjectsRead to
>>>>>>>>>>> manipulate
>>>>>>>>>>>>
>>>>>>>>>>>> project <dependencies>. This is what we do in Tycho, where we
>>>>>>>>>>>> resolve
>>>>>>>>>>>> project OSGi dependencies in AbstractMavenLifecycleParticipant
>>>>>>>>>>>> and
>>>>>>>>>>>> then
>>>>>>>>>>>> inject that into Maven project model as system scoped maven
>>>>>>>>>>>> dependencies.
>>>>>>>>>>>>
>>>>>>>>>>>> I also think your usecase highlights general deficiency with
>>>>>>>>>>>> current
>>>>>>>>>>>> dependency model. Since you have to add classpath elements
>>>>>>>>>>>> dynamically,
>>>>>>>>>>>> these elements are not visible to maven-based tools like m2e
>>>>>>>>>>>> without
>>>>>>>>>>>> additional effort on the tools part. I think it will be useful to
>>>>>>>>>>>> extend
>>>>>>>>>>>> <dependency> element syntax to allow references for nested
>>>>>>>>>>>> archive entries, i.e. "dependency on classes jar nested within
>>>>>>>>>>>> this
>>>>>>>>>>>> AAR
>>>>>>>>>>>> archive".
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/20/2014, 7:00, William Ferguson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I realise this question isn't exactly related to dev within the
>>>>>>>>>>>>> Maven
>>>>>>>>>>>>> components, but it is about developing a Mojo using components
>>>>>>>>>>>>> that
>>>>>>>>>>>>> have
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be pretty central and don't appear to be obviously documented
>>>>>>>>>>>>> anywhere.
>>>>>>>>>>>>> And
>>>>>>>>>>>>> I ahve asked on maven-users without much luck.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As part of the android-maven-plugin we have a Mojo which needs
>>>>>>>>>>>>> to
>>>>>>>>>>>>> add an
>>>>>>>>>>>>> element to the compile time classpath for future Mojos
>>>>>>>>>>>>> (specifically the
>>>>>>>>>>>>> maven-compiler-plugin).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Project has dependencies on artifacts of type AAR (Android
>>>>>>>>>>>>> archive
>>>>>>>>>>>>> - an
>>>>>>>>>>>>> archive that contains several sub-artifacts including a classes
>>>>>>>>>>>>> jar).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Our Mojo unpacks the AAR artifacts and makes the sub-artifacts
>>>>>>>>>>>>> available
>>>>>>>>>>>>> to
>>>>>>>>>>>>> other build components.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One of those build components is the maven-compiler-plugin. We
>>>>>>>>>>>>> want
>>>>>>>>>>>>> to
>>>>>>>>>>>>> add
>>>>>>>>>>>>> the classes contained in the AAR dependencies to the compile
>>>>>>>>>>>>> classpath
>>>>>>>>>>>>> so
>>>>>>>>>>>>> that the maven-compiler-plugin can compile our classes against
>>>>>>>>>>>>> the
>>>>>>>>>>>>> classes
>>>>>>>>>>>>> from the AARs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How do we do that?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> William
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>>> ---------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: reactorProjects vs. session.getProjects() Was: Re: Adding a classpath element within a Mojo
Posted by Jason van Zyl <ja...@takari.io>.
Yes.
On Feb 5, 2014, at 4:05 PM, Mirko Friedenhagen <mf...@gmail.com> wrote:
> Hello,
>
> just for my understanding:
> - Does the property reactorProjects[0] hold the projects in reactor build order?
>
> Regards Mirko
> [0] https://github.com/apache/maven-plugins/blob/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L68
>
> On Wed, Feb 5, 2014 at 1:56 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>> Maven first calls #afterProjectsRead(MavenSession), then calculates
>> reactor build order. So session.getProjects() still returns unsorted
>> project list during afterProjectsRead, which most likely does not matter
>> in your case.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 2/4/2014, 17:47, William Ferguson wrote:
>>>
>>> Can you explain the need to establish the reactor build order? I had
>>> expected session.getProjects() to have returned modules in the order they
>>> are defined. Are you saying that is not the case and that it would need to
>>> be configured by the LifeCycleParticipant?
>>>
>>> I think I can make the hack work. So I'll go with that for now. But I'd
>>> like to be able to annotate that with an issue number if there are plans
>>> to
>>> enhance the API on this front so that we know what and when to replace.
>>>
>>> I'd love to help enhance Maven (I have plenty to pay back for the hours it
>>> has saved me over the years) but I don't have the band width right now and
>>> I also don't feel like I have a good enough understanding of the Maven
>>> core. But as I said before if you think this is a worthwhile enterprise
>>> then help me create an issue that spells out what you think needs doing
>>> and
>>> I'll try to get back to it in a couple of months.
>>>
>>> William
>>>
>>>
>>>
>>> On Tue, Feb 4, 2014 at 10:39 PM, Igor Fedorenko <ig...@ifedorenko.com>
>>> wrote:
>>>
>>>>
>>>> On 2/4/2014, 1:06, William Ferguson wrote:
>>>>
>>>>> OK, I'm getting the dependencies to resolve and I can amend the
>>>>> classpath,
>>>>> but I think I've hit a road block for multi module builds.
>>>>>
>>>>> LifeCycleParticipant is only ever called once at the root. This means
>>>>> that
>>>>> if I have a project with 2 modules where ModuleB depends on ModuleA then
>>>>> I'm not going to be able extract and add ModuleA and it's classes when
>>>>> the
>>>>> LifeCycleParticipant executes because ModuleA will not have been built
>>>>> yet.
>>>>>
>>>>> Is there some way to get the LifeCycleParticipant called for every
>>>>> module
>>>>> of the build?
>>>>>
>>>>>
>>>> Looks like there are two related but distinct concerns there.
>>>>
>>>> First, it is necessary to establish reactor build order. This must
>>>> happen before actual build starts and lifecycle participant provides a
>>>> way to do this.
>>>>
>>>> Second, it is necessary to resolve dependencies among reactor modules.
>>>> This has to happen as part of the build itself and I don't think there
>>>> is an API for that yet.
>>>>
>>>> One hack-ish way to workaround this is to resolve reactor dependencies
>>>> is to create empty directories from lifecycle participant,
>>>> ModuleA/target/something in your case, and make sure ModuleA's build
>>>> populates the directory with expected files.
>>>>
>>>> Proper solution requires changes to maven core. I can provide some
>>>> pointers if you want to try this.
>>>>
>>>> --
>>>> Regards,
>>>> Igor
>>>>
>>>>
>>>> William
>>>>>
>>>>>
>>>>> William
>>>>>
>>>>>
>>>>> On Tue, Feb 4, 2014 at 12:46 PM, William Ferguson <
>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>
>>>>> Igor,
>>>>>>
>>>>>>
>>>>>> I've worked out how to modify the project classpath (pretty trivial).
>>>>>> But
>>>>>> I'm struggling to get the project dependencies resolved during
>>>>>> LifeCycleParticipant#afterProjectsRead.
>>>>>>
>>>>>> I tried using the TychoDependencyResolver to #setupProject and
>>>>>> #resolveProject but that isn't causing the projects dependencies to get
>>>>>> resolved. I'm not sure what I'm missing.
>>>>>>
>>>>>> I've created a cut down project dep-resolution-plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin.git
>>>>>> And a project that tests that plugin at
>>>>>> https://github.com/william-ferguson-au/dep-resolution-plugin-test.git
>>>>>> If you could have a look and point out what it is I'm missing I'd be
>>>>>> most
>>>>>> grateful.
>>>>>>
>>>>>> William
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 25, 2014 at 6:57 AM, William Ferguson <
>>>>>> william.ferguson@xandar.com.au> wrote:
>>>>>>
>>>>>> Maven 3.1.1 official, and all the plugin dependencies are 3.,1.1 too.
>>>>>>>
>>>>>>>
>>>>>>> I'll trying switching to the annotations. Javadoc annotations were
>>>>>>> just
>>>>>>> for conformity with the rest of the project.
>>>>>>>
>>>>>>> If that doesn't work, I'll put together a cut down example.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> William
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jan 23, 2014 at 9:43 PM, Igor Fedorenko <igor@ifedorenko.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> No, no tricks, as far as I know Plexus (and now Sisu/Guice) only
>>>>>>> inject
>>>>>>>>
>>>>>>>> fully configured components. so the behaviour you describe is rather
>>>>>>>> odd.
>>>>>>>>
>>>>>>>> What version of Maven do you use? Is it official distribution from
>>>>>>>> Apache or something you built locally?
>>>>>>>>
>>>>>>>> Not likely related, but I haven't used javadoc plexus annotations in
>>>>>>>> ages. Any particular reason you don't want to use java 5 @Component?
>>>>>>>>
>>>>>>>> In any case, if you can provide small standalone example that shows
>>>>>>>> the
>>>>>>>> problem, I can try to see what's going on there.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/23/2014, 0:54, William Ferguson wrote:
>>>>>>>>
>>>>>>>> Igor,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm having some difficulty getting the LifecycleParticipant to
>>>>>>>>> resolve
>>>>>>>>> Maven components.
>>>>>>>>>
>>>>>>>>> In particular, the org.apache.maven.project.
>>>>>>>>> ProjectDependenciesResolver.
>>>>>>>>> While it gets resolved, none of it's internal attributes get
>>>>>>>>> resolved.
>>>>>>>>> So
>>>>>>>>> calls to projectDependenciesResolver.resolve crash with NPEs because
>>>>>>>>> DefaultProjectDependenciesResolver#logger or #repoSystem is not
>>>>>>>>> initialised.
>>>>>>>>>
>>>>>>>>> /**
>>>>>>>>> * @component
>>>>>>>>> * @readonly
>>>>>>>>> * @required
>>>>>>>>> */
>>>>>>>>> protected ProjectDependenciesResolver
>>>>>>>>> projectDependenciesResolver;
>>>>>>>>>
>>>>>>>>> Is there some special trick to getting components fully initialised
>>>>>>>>> in a
>>>>>>>>> LifecycleParticipant?
>>>>>>>>>
>>>>>>>>> William
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko
>>>>>>>>> <igor@ifedorenko.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is Tycho lifecycle participant [1] and here is the code that
>>>>>>>>>
>>>>>>>>>> injects new dependencies in MavenProject instances [2].
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>>> TychoMavenLifecycleParticipant.java?h=tycho-0.19.x
>>>>>>>>>> [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/
>>>>>>>>>> tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/
>>>>>>>>>> MavenDependencyInjector.java?h=tycho-0.19.x
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Regards,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/20/2014, 8:21, William Ferguson wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks Igor,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> could you give me a link to an example or some code that
>>>>>>>>>>>
>>>>>>>>>>> - Utilises AbstractMavenLifecycleParticip
>>>>>>>>>>> ant#afterProjectsRead
>>>>>>>>>>> - How to manipulate the project <dependencies> from there.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I found an example example by Brett Porter, but the doco is pretty
>>>>>>>>>>> thin
>>>>>>>>>>> and
>>>>>>>>>>> I can't see how I would go about inject extra elements into the
>>>>>>>>>>> classpath
>>>>>>>>>>> from there.
>>>>>>>>>>>
>>>>>>>>>>> William
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko <
>>>>>>>>>>> igor@ifedorenko.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> There is probably more ways to do this, but you can implement
>>>>>>>>>>>
>>>>>>>>>>> AbstractMavenLifecycleParticipant#afterProjectsRead to
>>>>>>>>>>> manipulate
>>>>>>>>>>>>
>>>>>>>>>>>> project <dependencies>. This is what we do in Tycho, where we
>>>>>>>>>>>> resolve
>>>>>>>>>>>> project OSGi dependencies in AbstractMavenLifecycleParticipant
>>>>>>>>>>>> and
>>>>>>>>>>>> then
>>>>>>>>>>>> inject that into Maven project model as system scoped maven
>>>>>>>>>>>> dependencies.
>>>>>>>>>>>>
>>>>>>>>>>>> I also think your usecase highlights general deficiency with
>>>>>>>>>>>> current
>>>>>>>>>>>> dependency model. Since you have to add classpath elements
>>>>>>>>>>>> dynamically,
>>>>>>>>>>>> these elements are not visible to maven-based tools like m2e
>>>>>>>>>>>> without
>>>>>>>>>>>> additional effort on the tools part. I think it will be useful to
>>>>>>>>>>>> extend
>>>>>>>>>>>> <dependency> element syntax to allow references for nested
>>>>>>>>>>>> archive entries, i.e. "dependency on classes jar nested within
>>>>>>>>>>>> this
>>>>>>>>>>>> AAR
>>>>>>>>>>>> archive".
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Igor
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/20/2014, 7:00, William Ferguson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> I realise this question isn't exactly related to dev within the
>>>>>>>>>>>>> Maven
>>>>>>>>>>>>> components, but it is about developing a Mojo using components
>>>>>>>>>>>>> that
>>>>>>>>>>>>> have
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be pretty central and don't appear to be obviously documented
>>>>>>>>>>>>> anywhere.
>>>>>>>>>>>>> And
>>>>>>>>>>>>> I ahve asked on maven-users without much luck.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As part of the android-maven-plugin we have a Mojo which needs
>>>>>>>>>>>>> to
>>>>>>>>>>>>> add an
>>>>>>>>>>>>> element to the compile time classpath for future Mojos
>>>>>>>>>>>>> (specifically the
>>>>>>>>>>>>> maven-compiler-plugin).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Project has dependencies on artifacts of type AAR (Android
>>>>>>>>>>>>> archive
>>>>>>>>>>>>> - an
>>>>>>>>>>>>> archive that contains several sub-artifacts including a classes
>>>>>>>>>>>>> jar).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Our Mojo unpacks the AAR artifacts and makes the sub-artifacts
>>>>>>>>>>>>> available
>>>>>>>>>>>>> to
>>>>>>>>>>>>> other build components.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One of those build components is the maven-compiler-plugin. We
>>>>>>>>>>>>> want
>>>>>>>>>>>>> to
>>>>>>>>>>>>> add
>>>>>>>>>>>>> the classes contained in the AAR dependencies to the compile
>>>>>>>>>>>>> classpath
>>>>>>>>>>>>> so
>>>>>>>>>>>>> that the maven-compiler-plugin can compile our classes against
>>>>>>>>>>>>> the
>>>>>>>>>>>>> classes
>>>>>>>>>>>>> from the AARs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How do we do that?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> William
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>>> ---------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare