Re: DefaultMavenReaderFilter API does not correctly interpolate collection variables
Thanks both for your kind reply, very appreciated!
I was sure Plexus Interpolator supported that so I had the trouble I
was doing something wrong at API level :)
Keep up the good work, all the best!
~Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Tue, Oct 16, 2018 at 10:12 AM Olivier Lamy wrote:
>
> correct ATM we don't really have interpolation in such scripted way :(
>
>
> On Tue, 16 Oct 2018 at 18:07, Robert Scholte
> wrote:
>
> > I recognize the issue, but never paid attention to it since in general it
> > doesn't make sense to access any listing entry in the pom by index. I have
> > no solution here.
> > Robert
> > Verzonden vanaf mijn Samsung Galaxy-smartphone.
> > ---- Oorspronkelijk bericht Van: Simone Tripodi <
> > simonetrip...@apache.org> Datum: 15-10-18 12:12 (GMT+03:00) Aan: Maven
> > Developers List Onderwerp:
> > DefaultMavenReaderFilter API does not correctly interpolate
> > collection variables
> > Hi all mates,
> >
> > I am writing a plugin which needs to filter & then process resources,
> > I am using the DefaultMavenReaderFilter API below:
> >
> > DefaultMavenReaderFilter#filter( Reader, boolean, MavenProject,
> > List, boolean, MavenSession )
> >
> > in my resource I declared few variables that have to be interpolated,
> > everything works except:
> >
> > "license": "${project.licenses[0].name}"
> >
> > which is not interpolated and keeps to be represented as the original
> > string; if I try to replace it with
> >
> > "license": "${project.licenses}",
> >
> > it is correctly interpolated as
> >
> > "license":"[org.apache.maven.model.License@30135202]"
> >
> > Any idea what is wrong?
> > Many thanks in advance!
> > ~Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://twitter.com/simonetripodi
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
DefaultMavenReaderFilter API does not correctly interpolate collection variables
Hi all mates,
I am writing a plugin which needs to filter & then process resources,
I am using the DefaultMavenReaderFilter API below:
DefaultMavenReaderFilter#filter( Reader, boolean, MavenProject,
List, boolean, MavenSession )
in my resource I declared few variables that have to be interpolated,
everything works except:
"license": "${project.licenses[0].name}"
which is not interpolated and keeps to be represented as the original
string; if I try to replace it with
"license": "${project.licenses}",
it is correctly interpolated as
"license":"[org.apache.maven.model.License@30135202]"
Any idea what is wrong?
Many thanks in advance!
~Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
org.apache.maven.artifact.resolver.ArtifactResolver ignores packaging when resolving artifacts since mvn 3.1.1
Hi all mates, I faced today a strange issue(?) that I experienced with Maven 3.1.1 and 3.2.2: as per subject, org.apache.maven.artifact.resolver.ArtifactResolver ignores packaging when resolving artifacts, I mean that if a request com.acme:acme-commons:pom:1.7.0 the ArtifactResolver componnet tries to resolve http://nexus.acme.com/content/groups/development/com/acme/acme-commons/1.7.0/acme-commons-1.7.0 while the correct URL should be http://nexus.acme.com/content/groups/development/com/acme/acme-commons/1.7.0/acme-commons-1.7.0.pom It doesn't happen in Maven 3.0.5... Is it an issue? TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi
Inject Maven components/parameters to Plexus components
Hi all mates,
I am a little lost and I would like to kindly ask you if anyone knows
how to request, via Plexus annotations, the injection of Maven
parameters/components.
While for components I guess it is more or less the same as in MOJOs,
just using different kind annotations, it is not clear to me if it is
possible, and how, to request a MOJO parameter injection inside a
Plexus component, i.e. the ${project.groupId} or
${project.remotePluginRepositories}
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Inject Maven components/parameters to Plexus components
Thanks a lot for the clarification Jason, much more than appreciated!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Jun 23, 2014 at 3:00 PM, Jason van Zyl ja...@takari.io wrote:
The short answer is that you can't right now. We do not create bindings in
the normal JSR330 for configuration injection, we historically use a tool
called the PluginParameterExpressionEvaluator to pass over the component once
it's instantiated. We did this long before we used any container. As part of
the JSR330 work I'm doing I would like to dynamically create bindings so that
plugins can be simple POJOs using private/final constructor injection where
the bindings get created from the same process we use now except expose this
to the container during object instantiation.
Until that happens you can always make a singleton component and pass in your
configuration as parameters. If you need to manage state then you'll have to
do that yourself with a context of some sort.
On Jun 23, 2014, at 8:33 AM, Simone Tripodi simonetrip...@apache.org wrote:
Hi all mates,
I am a little lost and I would like to kindly ask you if anyone knows
how to request, via Plexus annotations, the injection of Maven
parameters/components.
While for components I guess it is more or less the same as in MOJOs,
just using different kind annotations, it is not clear to me if it is
possible, and how, to request a MOJO parameter injection inside a
Plexus component, i.e. the ${project.groupId} or
${project.remotePluginRepositories}
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: MRELEASE-431
Hello Robert, thanks a lot for your help, much more than appreciated! I've added the projectVersionPolicyId to the releaseDescriptor. We might need to add dependencyVersionPolicyId, parentVersionPolicyId and pluginVersionPolicyId in the future as well. So the manager is ready to switch from implementation, which should be enough for unittesting. We still need to make it available for the plugin. do you already have an idea how? I may can provide a patch for that... I think most version policies should have their own project+release-cycle, but it seems like the odd-even is a common policy, so I don't mind making it a separate module which will be part of the maven-release project. We can probably do something like enforcer: make a standard-policies module with common implementation. I am by your side! Although for now I wouldn't make it add it as dependency to the manager, users can do that themselves if they want. +1, I didn't touch indeed anything else than the new module and the reactor indeed, the odd-even policy impl has not to be part of the Robert All the best, -Simo -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi again Robert, IIUC the VersionPolicy resolution in `MapString, VersionPolicy versionPolicies` is strict to default only, moreover I didn't understand where/how to specify, in the plugin configuration, the `hint` of my VersionPolicy implementation... As a side note, I already have, in my local copy of the source code, a separated module with the odd-even policy implementation, included in the build - if there are not objections, I'd commit it, just let me know! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, http://svn.apache.org/r1578613 contains the default implementation for the maven-release-manager. Now it should be quite easy to test other policies. thanks, Robert ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Robert, yes I agree, while making my prototype - it will be opensourced, by the way - I also realised that my Policy implementation is the wrong Maven phase: when asking for the next release version, it is supposed that current doesn't exist yet (unless someone publishes the SNAPSHOT, even locally) so artifact diff cannot be executed. That would force users configuring the release plugin in order to invoke the `package` first... I don't have strong opinions ATM on how the new interface should look alike... Thanks a lot for you efforts! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I think what you want is a way to make clear what kind of release it will be: major, minor, bugfix/micro. That's something which can be added to the request and looks reasonable for all policies. I'm not sure if an enum is correct here, any founded suggestion is welcome. However, the calculation what kind of of release it should be, belongs in another class in my opinion. So let's think of another interface :) Robert Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob, thanks a lot for the detailed feedback, very appreciated :) I just realise I didn't pass you enough informations to better understand the new context we are working on: in the OSGi world, aside the odd-even policy, we would like to wrap BND[1] APis which allow compare two bundles and understand, via bytecode analysis[2], which should be the suggested version; that is why I need the ArtifactResolver, in order to get the latest released artifact (or specify the version, somehow) and compare it to the one is going to be released, in order let BND calculate the suggested version. I hope that scenario makes more clear why I asked how to inject other components! All the best! -Simo [1] http://www.aqute.biz/Bnd/ [2] http://www.aqute.biz/Bnd/Versioning http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote: To say
Re: MRELEASE-431
Hi again Robert, I checked in the odd-even module in r1580793 - every feedback/suggestion/... is, as usual, much more than welcome and appreciated :) All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 22, 2014 at 1:10 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I've added the projectVersionPolicyId to the releaseDescriptor. We might need to add dependencyVersionPolicyId, parentVersionPolicyId and pluginVersionPolicyId in the future as well. So the manager is ready to switch from implementation, which should be enough for unittesting. We still need to make it available for the plugin. I think most version policies should have their own project+release-cycle, but it seems like the odd-even is a common policy, so I don't mind making it a separate module which will be part of the maven-release project. We can probably do something like enforcer: make a standard-policies module with common implementation. Although for now I wouldn't make it add it as dependency to the manager, users can do that themselves if they want. Robert Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi again Robert, IIUC the VersionPolicy resolution in `MapString, VersionPolicy versionPolicies` is strict to default only, moreover I didn't understand where/how to specify, in the plugin configuration, the `hint` of my VersionPolicy implementation... As a side note, I already have, in my local copy of the source code, a separated module with the odd-even policy implementation, included in the build - if there are not objections, I'd commit it, just let me know! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, http://svn.apache.org/r1578613 contains the default implementation for the maven-release-manager. Now it should be quite easy to test other policies. thanks, Robert ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Robert, yes I agree, while making my prototype - it will be opensourced, by the way - I also realised that my Policy implementation is the wrong Maven phase: when asking for the next release version, it is supposed that current doesn't exist yet (unless someone publishes the SNAPSHOT, even locally) so artifact diff cannot be executed. That would force users configuring the release plugin in order to invoke the `package` first... I don't have strong opinions ATM on how the new interface should look alike... Thanks a lot for you efforts! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I think what you want is a way to make clear what kind of release it will be: major, minor, bugfix/micro. That's something which can be added to the request and looks reasonable for all policies. I'm not sure if an enum is correct here, any founded suggestion is welcome. However, the calculation what kind of of release it should be, belongs in another class in my opinion. So let's think of another interface :) Robert Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob, thanks a lot for the detailed feedback, very appreciated :) I just realise I didn't pass you enough informations to better understand the new context we are working on: in the OSGi world, aside the odd-even policy, we would like to wrap BND[1] APis which allow compare two bundles and understand, via bytecode analysis[2], which should be the suggested version; that is why I need the ArtifactResolver, in order to get the latest released artifact (or specify the version, somehow) and compare it to the one is going to be released, in order let BND calculate the suggested version. I hope that scenario makes more clear why I asked how to inject other components! All the best! -Simo [1] http://www.aqute.biz/Bnd/ [2] http://www.aqute.biz/Bnd/Versioning http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote: To say it in your own words: IMHO I think you're wrong here ;) Version policy
Re: MRELEASE-431
Hi Robert! sorry to come back so late, got busy with other stuff at work :( Thanks *a lot* for providing APIs change - I am going to test them in the afternoon! Since I have karma on Mvn repo... would it make sense I contribute directly there the odd-even policy implementation? Maybe in a separated module? It costs 0 to me... just let me know! :) Have a nice day! -Simo PS apologise, but since I joined Adobe CH, I write Alles Gute automatically without even thinking who's the receiver I am writing :D http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, http://svn.apache.org/r1578613 contains the default implementation for the maven-release-manager. Now it should be quite easy to test other policies. thanks, Robert ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Robert, yes I agree, while making my prototype - it will be opensourced, by the way - I also realised that my Policy implementation is the wrong Maven phase: when asking for the next release version, it is supposed that current doesn't exist yet (unless someone publishes the SNAPSHOT, even locally) so artifact diff cannot be executed. That would force users configuring the release plugin in order to invoke the `package` first... I don't have strong opinions ATM on how the new interface should look alike... Thanks a lot for you efforts! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I think what you want is a way to make clear what kind of release it will be: major, minor, bugfix/micro. That's something which can be added to the request and looks reasonable for all policies. I'm not sure if an enum is correct here, any founded suggestion is welcome. However, the calculation what kind of of release it should be, belongs in another class in my opinion. So let's think of another interface :) Robert Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob, thanks a lot for the detailed feedback, very appreciated :) I just realise I didn't pass you enough informations to better understand the new context we are working on: in the OSGi world, aside the odd-even policy, we would like to wrap BND[1] APis which allow compare two bundles and understand, via bytecode analysis[2], which should be the suggested version; that is why I need the ArtifactResolver, in order to get the latest released artifact (or specify the version, somehow) and compare it to the one is going to be released, in order let BND calculate the suggested version. I hope that scenario makes more clear why I asked how to inject other components! All the best! -Simo [1] http://www.aqute.biz/Bnd/ [2] http://www.aqute.biz/Bnd/Versioning http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote: To say it in your own words: IMHO I think you're wrong here ;) Version policy is about calculating the next version based on an input version. These are valid examples: default policy: getReleaseVersion(1-SNAPSHOT) = 1 getReleaseVersion(1.0-SNAPSHOT) = 1.0 getReleaseVersion(1.0.0-SNAPSHOT) = 1.0.0 getDevelopmentVersion(1) = 2-SNAPSHOT getDevelopmentVersion(1.0) = 1.1-SNAPSHOT getDevelopmentVersion(1.0.0) = 1.0.1-SNAPSHOT odd-even getReleaseVersion(1.0-SNAPSHOT) = 1.1 getDevelopmentVersion(1.1) = 1.2-SNAPSHOT the metadata gives the following opportunity: suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 - 3.1.5-SNAPSHOT it'll be 3.1.4 - 3.2-SNAPSHOT I think it's weird to depend the policy on the GAV. Just choose a proper policy for your project. I also think that the ArtifactResolver is not required here. It's like instead of passing a string-based version, you'd like to pass an artifact and extract it's version. My idea is the other way around: extract the version from the artifact first and pass that to the policy. I would expect it to be the version in the pom.xml. If you want to check it, use an enforcer rule or something like that. We should try to keep
Re: MRELEASE-431
Hi again Robert, IIUC the VersionPolicy resolution in `MapString, VersionPolicy versionPolicies` is strict to default only, moreover I didn't understand where/how to specify, in the plugin configuration, the `hint` of my VersionPolicy implementation... As a side note, I already have, in my local copy of the source code, a separated module with the odd-even policy implementation, included in the build - if there are not objections, I'd commit it, just let me know! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, http://svn.apache.org/r1578613 contains the default implementation for the maven-release-manager. Now it should be quite easy to test other policies. thanks, Robert ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Robert, yes I agree, while making my prototype - it will be opensourced, by the way - I also realised that my Policy implementation is the wrong Maven phase: when asking for the next release version, it is supposed that current doesn't exist yet (unless someone publishes the SNAPSHOT, even locally) so artifact diff cannot be executed. That would force users configuring the release plugin in order to invoke the `package` first... I don't have strong opinions ATM on how the new interface should look alike... Thanks a lot for you efforts! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I think what you want is a way to make clear what kind of release it will be: major, minor, bugfix/micro. That's something which can be added to the request and looks reasonable for all policies. I'm not sure if an enum is correct here, any founded suggestion is welcome. However, the calculation what kind of of release it should be, belongs in another class in my opinion. So let's think of another interface :) Robert Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob, thanks a lot for the detailed feedback, very appreciated :) I just realise I didn't pass you enough informations to better understand the new context we are working on: in the OSGi world, aside the odd-even policy, we would like to wrap BND[1] APis which allow compare two bundles and understand, via bytecode analysis[2], which should be the suggested version; that is why I need the ArtifactResolver, in order to get the latest released artifact (or specify the version, somehow) and compare it to the one is going to be released, in order let BND calculate the suggested version. I hope that scenario makes more clear why I asked how to inject other components! All the best! -Simo [1] http://www.aqute.biz/Bnd/ [2] http://www.aqute.biz/Bnd/Versioning http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote: To say it in your own words: IMHO I think you're wrong here ;) Version policy is about calculating the next version based on an input version. These are valid examples: default policy: getReleaseVersion(1-SNAPSHOT) = 1 getReleaseVersion(1.0-SNAPSHOT) = 1.0 getReleaseVersion(1.0.0-SNAPSHOT) = 1.0.0 getDevelopmentVersion(1) = 2-SNAPSHOT getDevelopmentVersion(1.0) = 1.1-SNAPSHOT getDevelopmentVersion(1.0.0) = 1.0.1-SNAPSHOT odd-even getReleaseVersion(1.0-SNAPSHOT) = 1.1 getDevelopmentVersion(1.1) = 1.2-SNAPSHOT the metadata gives the following opportunity: suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 - 3.1.5-SNAPSHOT it'll be 3.1.4 - 3.2-SNAPSHOT I think it's weird to depend the policy on the GAV. Just choose a proper policy for your project. I also think that the ArtifactResolver is not required here. It's like instead of passing a string-based version, you'd like to pass an artifact and extract it's version. My idea is the other way around: extract the version from the artifact first and pass that to the policy. I would expect it to be the version in the pom.xml. If you want to check it, use an enforcer rule or something like that. We should try to keep the task of this class
Re: MRELEASE-431
Hi Robert, after an internal discussion with my colleagues, we are ATM fine with just implementing the odd-even policy, so let's forget my prototype ATM, we are fine with current new APIs. Is there anything I can help you in order to have them integrated in the release-plugin? TIA, Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Robert, yes I agree, while making my prototype - it will be opensourced, by the way - I also realised that my Policy implementation is the wrong Maven phase: when asking for the next release version, it is supposed that current doesn't exist yet (unless someone publishes the SNAPSHOT, even locally) so artifact diff cannot be executed. That would force users configuring the release plugin in order to invoke the `package` first... I don't have strong opinions ATM on how the new interface should look alike... Thanks a lot for you efforts! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I think what you want is a way to make clear what kind of release it will be: major, minor, bugfix/micro. That's something which can be added to the request and looks reasonable for all policies. I'm not sure if an enum is correct here, any founded suggestion is welcome. However, the calculation what kind of of release it should be, belongs in another class in my opinion. So let's think of another interface :) Robert Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob, thanks a lot for the detailed feedback, very appreciated :) I just realise I didn't pass you enough informations to better understand the new context we are working on: in the OSGi world, aside the odd-even policy, we would like to wrap BND[1] APis which allow compare two bundles and understand, via bytecode analysis[2], which should be the suggested version; that is why I need the ArtifactResolver, in order to get the latest released artifact (or specify the version, somehow) and compare it to the one is going to be released, in order let BND calculate the suggested version. I hope that scenario makes more clear why I asked how to inject other components! All the best! -Simo [1] http://www.aqute.biz/Bnd/ [2] http://www.aqute.biz/Bnd/Versioning http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote: To say it in your own words: IMHO I think you're wrong here ;) Version policy is about calculating the next version based on an input version. These are valid examples: default policy: getReleaseVersion(1-SNAPSHOT) = 1 getReleaseVersion(1.0-SNAPSHOT) = 1.0 getReleaseVersion(1.0.0-SNAPSHOT) = 1.0.0 getDevelopmentVersion(1) = 2-SNAPSHOT getDevelopmentVersion(1.0) = 1.1-SNAPSHOT getDevelopmentVersion(1.0.0) = 1.0.1-SNAPSHOT odd-even getReleaseVersion(1.0-SNAPSHOT) = 1.1 getDevelopmentVersion(1.1) = 1.2-SNAPSHOT the metadata gives the following opportunity: suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 - 3.1.5-SNAPSHOT it'll be 3.1.4 - 3.2-SNAPSHOT I think it's weird to depend the policy on the GAV. Just choose a proper policy for your project. I also think that the ArtifactResolver is not required here. It's like instead of passing a string-based version, you'd like to pass an artifact and extract it's version. My idea is the other way around: extract the version from the artifact first and pass that to the policy. I would expect it to be the version in the pom.xml. If you want to check it, use an enforcer rule or something like that. We should try to keep the task of this class as simple as possible. Robert Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi again Robert, sorry for bugging - I hope I don't :P - but I notice Metadata also has a very limited subset of informations about the ongoing released artifact. IMHO informations such us packaging and classifier should be part of that data set - maybe I am wrong and work around that? TIA, All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, for that reason I've added the Metadata, from which you can get the latest released artifact. I really hope you don't need the ArtifactResolver. Robert Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi again Robert, in one of my VersionPolicy implementations, I need to resolve the latest release artifact - then I have a tool to compare
Re: MRELEASE-431
Hi Rob,
thanks a lot for the detailed feedback, very appreciated :)
I just realise I didn't pass you enough informations to better
understand the new context we are working on: in the OSGi world, aside
the odd-even policy, we would like to wrap BND[1] APis which allow
compare two bundles and understand, via bytecode analysis[2], which
should be the suggested version; that is why I need the
ArtifactResolver, in order to get the latest released artifact (or
specify the version, somehow) and compare it to the one is going to be
released, in order let BND calculate the suggested version.
I hope that scenario makes more clear why I asked how to inject other
components!
All the best!
-Simo
[1] http://www.aqute.biz/Bnd/
[2] http://www.aqute.biz/Bnd/Versioning
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org wrote:
To say it in your own words: IMHO I think you're wrong here ;)
Version policy is about calculating the next version based on an input
version.
These are valid examples:
default policy:
getReleaseVersion(1-SNAPSHOT) = 1
getReleaseVersion(1.0-SNAPSHOT) = 1.0
getReleaseVersion(1.0.0-SNAPSHOT) = 1.0.0
getDevelopmentVersion(1) = 2-SNAPSHOT
getDevelopmentVersion(1.0) = 1.1-SNAPSHOT
getDevelopmentVersion(1.0.0) = 1.0.1-SNAPSHOT
odd-even
getReleaseVersion(1.0-SNAPSHOT) = 1.1
getDevelopmentVersion(1.1) = 1.2-SNAPSHOT
the metadata gives the following opportunity:
suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 -
3.1.5-SNAPSHOT it'll be 3.1.4 - 3.2-SNAPSHOT
I think it's weird to depend the policy on the GAV. Just choose a proper
policy for your project.
I also think that the ArtifactResolver is not required here.
It's like instead of passing a string-based version, you'd like to pass an
artifact and extract it's version.
My idea is the other way around: extract the version from the artifact first
and pass that to the policy.
I would expect it to be the version in the pom.xml. If you want to check it,
use an enforcer rule or something like that.
We should try to keep the task of this class as simple as possible.
Robert
Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the
latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
${project.remoteArtifactRepositories}, readonly = true)
private ListArtifactRepository remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can
be
thrown with the current implementation of DefaultVersionInfo. I
probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for
putting
effort on that!
I maybe missed something but I didn't notice how they are integrated
in
the
core module...
TIA all the best!
-Simo
Re: MRELEASE-431
Hi Robert,
yes I agree, while making my prototype - it will be opensourced, by
the way - I also realised that my Policy implementation is the wrong
Maven phase: when asking for the next release version, it is supposed
that current doesn't exist yet (unless someone publishes the SNAPSHOT,
even locally) so artifact diff cannot be executed.
That would force users configuring the release plugin in order to
invoke the `package` first...
I don't have strong opinions ATM on how the new interface should look alike...
Thanks a lot for you efforts!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte rfscho...@apache.org wrote:
Hi Simone,
I think what you want is a way to make clear what kind of release it will
be: major, minor, bugfix/micro.
That's something which can be added to the request and looks reasonable for
all policies. I'm not sure if an enum is correct here, any founded
suggestion is welcome.
However, the calculation what kind of of release it should be, belongs in
another class in my opinion.
So let's think of another interface :)
Robert
Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob,
thanks a lot for the detailed feedback, very appreciated :)
I just realise I didn't pass you enough informations to better
understand the new context we are working on: in the OSGi world, aside
the odd-even policy, we would like to wrap BND[1] APis which allow
compare two bundles and understand, via bytecode analysis[2], which
should be the suggested version; that is why I need the
ArtifactResolver, in order to get the latest released artifact (or
specify the version, somehow) and compare it to the one is going to be
released, in order let BND calculate the suggested version.
I hope that scenario makes more clear why I asked how to inject other
components!
All the best!
-Simo
[1] http://www.aqute.biz/Bnd/
[2] http://www.aqute.biz/Bnd/Versioning
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Thu, Mar 13, 2014 at 7:19 PM, Robert Scholte rfscho...@apache.org
wrote:
To say it in your own words: IMHO I think you're wrong here ;)
Version policy is about calculating the next version based on an input
version.
These are valid examples:
default policy:
getReleaseVersion(1-SNAPSHOT) = 1
getReleaseVersion(1.0-SNAPSHOT) = 1.0
getReleaseVersion(1.0.0-SNAPSHOT) = 1.0.0
getDevelopmentVersion(1) = 2-SNAPSHOT
getDevelopmentVersion(1.0) = 1.1-SNAPSHOT
getDevelopmentVersion(1.0.0) = 1.0.1-SNAPSHOT
odd-even
getReleaseVersion(1.0-SNAPSHOT) = 1.1
getDevelopmentVersion(1.1) = 1.2-SNAPSHOT
the metadata gives the following opportunity:
suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case
you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 -
3.1.5-SNAPSHOT it'll be 3.1.4 - 3.2-SNAPSHOT
I think it's weird to depend the policy on the GAV. Just choose a proper
policy for your project.
I also think that the ArtifactResolver is not required here.
It's like instead of passing a string-based version, you'd like to pass
an
artifact and extract it's version.
My idea is the other way around: extract the version from the artifact
first
and pass that to the policy.
I would expect it to be the version in the pom.xml. If you want to check
it,
use an enforcer rule or something like that.
We should try to keep the task of this class as simple as possible.
Robert
Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the
latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository
Re: MRELEASE-431
Hi Rob!
I honestly need to access to latest released physical artifact,
because I need to wrap a tool which is able to detect bytecode
differences between the latest released artifact and the current
ongoing to be released, then gives an estimation on which version
number should be released.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte rfscho...@apache.org wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
${project.remoteArtifactRepositories}, readonly = true)
private ListArtifactRepository remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can
be
thrown with the current implementation of DefaultVersionInfo. I probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I've added a new module for Maven release policies including my idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation in
the
plugin configuration, I now prefer to use it as a component. Downside
is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other components
a.k.a
requirements. Since this might become quite complicated, injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate - I
need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that allow
me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi all mates,
I am in a phase where I could get benefit of that feature as well
(and,
since I am still in the committer list, I can provide some help
here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA, I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com
Re: MRELEASE-431
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte rfscho...@apache.org wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
${project.remoteArtifactRepositories}, readonly = true)
private ListArtifactRepository remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can
be
thrown with the current implementation of DefaultVersionInfo. I probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I've added a new module for Maven release policies including my idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation in
the
plugin configuration, I now prefer to use it as a component. Downside
is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other components
a.k.a
requirements. Since this might become quite complicated, injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate - I
need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that allow
me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi all mates,
I am in a phase where I could get benefit of that feature as well
(and,
since I am still in the committer list, I can provide some help
here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA, I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
Re: MRELEASE-431
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
${project.remoteArtifactRepositories}, readonly = true)
private ListArtifactRepository remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can be
thrown with the current implementation of DefaultVersionInfo. I probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I've added a new module for Maven release policies including my idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation in
the
plugin configuration, I now prefer to use it as a component. Downside is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other components
a.k.a
requirements. Since this might become quite complicated, injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate - I need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that allow me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi all mates,
I am in a phase where I could get benefit of that feature as well
(and,
since I am still in the committer list, I can provide some help here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA, I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
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
-
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: MRELEASE-431
Hi Igor,
There will be an option to specify the specific release version to
handle such situations, but let's do one step at a time :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 2:05 PM, Igor Fedorenko i...@ifedorenko.com wrote:
Out of curiosity, how do you plan to deal with multiple development
streams with different latest version depending on the stream? If, for
example, somebody decided to release maven 3.0.6, it'd need to be
compared to 3.0.5, not 3.2.1.
--
Regards,
Igor
On 2014-03-12, 8:30, Simone Tripodi wrote:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = ${localRepository},
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
${project.remoteArtifactRepositories}, readonly = true)
private ListArtifactRepository remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can
be
thrown with the current implementation of DefaultVersionInfo. I probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I've added a new module for Maven release policies including my idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation in
the
plugin configuration, I now prefer to use it as a component. Downside
is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other components
a.k.a
requirements. Since this might become quite complicated, injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate - I
need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that allow
me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi all mates,
I am in a phase where I could get benefit of that feature as well
(and,
since I am still in the committer list, I can provide some help
here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA, I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
To unsubscribe, e-mail: dev-unsubscr
Re: MRELEASE-431
Hi Robert,
+1 - given my current experimental implementation, I am convinced that
declaring the VersionPolicy as component is the way to go, so I can
even inject whatever I need in order to implement my policy to
increase versions :)
Thanks,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte rfscho...@apache.org wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which can be
thrown with the current implementation of DefaultVersionInfo. I probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = tripodi )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for putting
effort on that!
I maybe missed something but I didn't notice how they are integrated in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
I've added a new module for Maven release policies including my idea of
how the API should look like.
Although one of my suggestions to specify this as an implementation in
the
plugin configuration, I now prefer to use it as a component. Downside is
that you can't use a pojo, you'll need to add Plexus annotations and
generate the descriptor. However, now you can inject other components
a.k.a
requirements. Since this might become quite complicated, injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate - I need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that allow me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org
wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi
simonetrip...@apache.org:
Hi all mates,
I am in a phase where I could get benefit of that feature as well
(and,
since I am still in the committer list, I can provide some help here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA, I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
-
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
-
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: MRELEASE-431
Hi Robert! amazing, I am having a look at it ASAP - anyway, DI sounds to be the way to go :) All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I've added a new module for Maven release policies including my idea of how the API should look like. Although one of my suggestions to specify this as an implementation in the plugin configuration, I now prefer to use it as a component. Downside is that you can't use a pojo, you'll need to add Plexus annotations and generate the descriptor. However, now you can inject other components a.k.a requirements. Since this might become quite complicated, injection is probably the preferred way. I probably need more info in the PolicyRequest to support the current behavior, but this is just a start. This should be a good start for you too. Let me know if this will work with your requirements. best, Robert Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob! :) indeed it has been a very long while, so sorry for that :( OK I understand your PoV, count on me if you want to co-operate - I need that feature as well in order to make the release-plugin able to generate that version using a tool, but without exposing such APIs that allow me plugging different versioning systems, I cannot do it :) Many thanks in advance and have a nice weekend! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, It's been a while, so I'll need to have another look at this. At first glance I'm not yet happy with the suggested API. I'd need to make some time so come with a final solution. Robert Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi all mates, I am in a phase where I could get benefit of that feature as well (and, since I am still in the committer list, I can provide some help here) so I would like to push it :P @Robert: before merging the contribution we received in JIRA, I'd kindly ask if you had a better idea if new API has to be in the maven-release-manager or in a separate module. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi - 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: MRELEASE-431
Hi again Robert, new APIs look reasonable and easily extensible to me, thanks for putting effort on that! I maybe missed something but I didn't notice how they are integrated in the core module... TIA all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, I've added a new module for Maven release policies including my idea of how the API should look like. Although one of my suggestions to specify this as an implementation in the plugin configuration, I now prefer to use it as a component. Downside is that you can't use a pojo, you'll need to add Plexus annotations and generate the descriptor. However, now you can inject other components a.k.a requirements. Since this might become quite complicated, injection is probably the preferred way. I probably need more info in the PolicyRequest to support the current behavior, but this is just a start. This should be a good start for you too. Let me know if this will work with your requirements. best, Robert Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi Rob! :) indeed it has been a very long while, so sorry for that :( OK I understand your PoV, count on me if you want to co-operate - I need that feature as well in order to make the release-plugin able to generate that version using a tool, but without exposing such APIs that allow me plugging different versioning systems, I cannot do it :) Many thanks in advance and have a nice weekend! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.org wrote: Hi Simone, It's been a while, so I'll need to have another look at this. At first glance I'm not yet happy with the suggested API. I'd need to make some time so come with a final solution. Robert Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi all mates, I am in a phase where I could get benefit of that feature as well (and, since I am still in the committer list, I can provide some help here) so I would like to push it :P @Robert: before merging the contribution we received in JIRA, I'd kindly ask if you had a better idea if new API has to be in the maven-release-manager or in a separate module. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi - 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
MRELEASE-431
Hi all mates, I am in a phase where I could get benefit of that feature as well (and, since I am still in the committer list, I can provide some help here) so I would like to push it :P @Robert: before merging the contribution we received in JIRA, I'd kindly ask if you had a better idea if new API has to be in the maven-release-manager or in a separate module. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi
Re: MRELEASE-431
Hi Rob! :) indeed it has been a very long while, so sorry for that :( OK I understand your PoV, count on me if you want to co-operate - I need that feature as well in order to make the release-plugin able to generate that version using a tool, but without exposing such APIs that allow me plugging different versioning systems, I cannot do it :) Many thanks in advance and have a nice weekend! All the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte rfscho...@apache.orgwrote: Hi Simone, It's been a while, so I'll need to have another look at this. At first glance I'm not yet happy with the suggested API. I'd need to make some time so come with a final solution. Robert Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi all mates, I am in a phase where I could get benefit of that feature as well (and, since I am still in the committer list, I can provide some help here) so I would like to push it :P @Robert: before merging the contribution we received in JIRA, I'd kindly ask if you had a better idea if new API has to be in the maven-release-manager or in a separate module. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl ja...@tesla.io wrote: Agreed. Our tooling and policy is embodied in the release plugin. I am personally fine with any policy changes that are required, but would argue anything we have is grandfathered in because we've been doing it so long. If changes are required, my requirement is that I do nothing more than I currently do which is to use the release plugin. I agree with Ralph that your avenue of change is by altering the release plugin because this discussion isn't going to result in anything unless it results in changes to the release plugin. +1 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Jun 27, 2013, at 10:05 AM, Ralph Goers rgo...@apache.org wrote: I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid. Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin. Ralph On Jun 25, 2013, at 4:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, sebb wrote: The mission of the ASF is to release software as source, and to ensure that the released source is available under the Apache Licence. Before a release can be approved it must be voted on by the PMC. The review process needs to establish that the proposed source release meets those aims. It's all but impossible for reviewers to examine every single file in a source archive to determine if it meets the criteria. And it's not unknown for spurious files to creep into a release (perhaps from a stale workspace - are releases always built from a fresh checkout of the tag?) However, PMCs are also required to check what is added to the SCM (SVN/Git) to make sure it meets the required license criteria. This is done on an ongoing basis as part of reviewing check-ins and accepting new contributions. So provided that all the files in the source release are also present in SCM, the PMC can be reasonably sure that the source release meets the ASF criteria. Without having the SCM as a database of validated files, there are far too many files in the average source archive to check individually. And how would one check their provenance? The obvious way is to compare them with the entries in SCM. Therefore, I contend that a release vote does not make sense without the SCM tag. In the case of SVN, since tags are not immutable, the vote e-mail also needs the revision. Whether every reviewer actually checks the source archive against SCM is another matter. But if the required SCM information is not present, it would be difficult to argue that the RM had provided sufficient information for a valid review to take place. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
[food for thoughts] becoming polyglot
Hi all guys, I recently added in current Modello development version (1.8-SNAPSHOT) support for JSON, JSON Schema and YAML generation (aside of inner Builder and static utility method generation to create objects instances) and experimented - of course! - to blindly generate the new (un)marshallers for the Maven model, when... stumbled in the plugin `configuration` element which is a DOM object. That made me unable to go ahead and stop investigating on how to become polyglot without pain using JSON and YAML formats. If you are curious to see how the JSON-ized[1] and the YAML-ized[2] version of the POM would look alike, without installing the Modello SNAPSHOT, just follow the links. Do you have suggestion on how to plug a good support for plugin configuration element in order to still support the JSON/YAML syntax but (un)marshalling it to DOM, in order to become polyglot? Many thanks in advance, all the best! -Simo [1] https://gist.github.com/simonetripodi/5688663 [2] https://gist.github.com/simonetripodi/5702523 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [doap-plugin] shortdesc property value not interpolated?
Salut Vincent!
Is the doap-plugin code still on SVN or has been migrated to Git?
Just to see if I am able to fix it by myself...
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Jan 8, 2013 at 12:35 PM, Vincent Siveton
vincent.sive...@gmail.com wrote:
Hi Simone!
Probably a bug.
DoapUtil.interpolate() should does the job.
Please create an issue with your project.
V.
2013/1/8 Simone Tripodi simonetrip...@apache.org:
Salut Olivier!
Note project.description is the default value :-)
yes that is why I got crazy :P
Is-it an open source with this issue ?
Yes I just included it in the Onami parent on /trunk. If I launch
`mvn install site`
I got the following error
[INFO] --- maven-doap-plugin:1.1:generate (site) @ org.apache.onami.parent
---
[INFO] This project is an ASF project, ASF Extensions to DOAP will be added.
[INFO] Generating an ASF DOAP file
/Users/stripodi/Documents/apache-workspace/onami/trunk/parent/target/site/doap.rdf
[ERROR]
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the plugin documentation:
[ERROR]
http://maven.apache.org/plugins/maven-doap-plugin/usage.html#DOAP_ASF_Configuration
Any idea?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jan 7, 2013 at 9:52 PM, Olivier Lamy ol...@apache.org wrote:
Hi Simo,
I just changed an it with that and cannot reproduce.
2013/1/7 Simone Tripodi simonetrip...@apache.org:
Hi mates,
forwarding to dev@ - is that a bug?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-- Forwarded message --
From: Simone Tripodi simonetrip...@apache.org
Date: Sun, Jan 6, 2013 at 8:41 PM
Subject: [doap-plugin] shortdesc property value not interpolated?
To: Maven Users List us...@maven.apache.org
Hi all guys,
I am tryin' to plug the doap-plugin in Apache Onami and I noticed a
strange behaviour of the `shotdesc` property.
If not specified, the plugin terminates with an error:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I specify as
doapOptions
shortdesc${project.description}/shortdesc
/doapOptions
it terminates with the same error message:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I set a value, such as
doapOptions
shortdescBazinga!/shortdesc
/doapOptions
It goes ok.
Ah, and yes, the ${project.description} property is specified :)
Is there something I overlooked or maybe a known issue?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [doap-plugin] shortdesc property value not interpolated?
Salut Vincent!
I recorder that issue on MDOAP-38 :)
Many thanks in advance, all the best!
-Simo
[1] https://jira.codehaus.org/browse/MDOAP-38
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Jan 8, 2013 at 12:35 PM, Vincent Siveton
vincent.sive...@gmail.com wrote:
Hi Simone!
Probably a bug.
DoapUtil.interpolate() should does the job.
Please create an issue with your project.
V.
2013/1/8 Simone Tripodi simonetrip...@apache.org:
Salut Olivier!
Note project.description is the default value :-)
yes that is why I got crazy :P
Is-it an open source with this issue ?
Yes I just included it in the Onami parent on /trunk. If I launch
`mvn install site`
I got the following error
[INFO] --- maven-doap-plugin:1.1:generate (site) @ org.apache.onami.parent
---
[INFO] This project is an ASF project, ASF Extensions to DOAP will be added.
[INFO] Generating an ASF DOAP file
/Users/stripodi/Documents/apache-workspace/onami/trunk/parent/target/site/doap.rdf
[ERROR]
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the plugin documentation:
[ERROR]
http://maven.apache.org/plugins/maven-doap-plugin/usage.html#DOAP_ASF_Configuration
Any idea?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jan 7, 2013 at 9:52 PM, Olivier Lamy ol...@apache.org wrote:
Hi Simo,
I just changed an it with that and cannot reproduce.
2013/1/7 Simone Tripodi simonetrip...@apache.org:
Hi mates,
forwarding to dev@ - is that a bug?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-- Forwarded message --
From: Simone Tripodi simonetrip...@apache.org
Date: Sun, Jan 6, 2013 at 8:41 PM
Subject: [doap-plugin] shortdesc property value not interpolated?
To: Maven Users List us...@maven.apache.org
Hi all guys,
I am tryin' to plug the doap-plugin in Apache Onami and I noticed a
strange behaviour of the `shotdesc` property.
If not specified, the plugin terminates with an error:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I specify as
doapOptions
shortdesc${project.description}/shortdesc
/doapOptions
it terminates with the same error message:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I set a value, such as
doapOptions
shortdescBazinga!/shortdesc
/doapOptions
It goes ok.
Ah, and yes, the ${project.description} property is specified :)
Is there something I overlooked or maybe a known issue?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Fwd: [doap-plugin] shortdesc property value not interpolated?
Hi mates,
forwarding to dev@ - is that a bug?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-- Forwarded message --
From: Simone Tripodi simonetrip...@apache.org
Date: Sun, Jan 6, 2013 at 8:41 PM
Subject: [doap-plugin] shortdesc property value not interpolated?
To: Maven Users List us...@maven.apache.org
Hi all guys,
I am tryin' to plug the doap-plugin in Apache Onami and I noticed a
strange behaviour of the `shotdesc` property.
If not specified, the plugin terminates with an error:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by ASF.
If I specify as
doapOptions
shortdesc${project.description}/shortdesc
/doapOptions
it terminates with the same error message:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by ASF.
If I set a value, such as
doapOptions
shortdescBazinga!/shortdesc
/doapOptions
It goes ok.
Ah, and yes, the ${project.description} property is specified :)
Is there something I overlooked or maybe a known issue?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [doap-plugin] shortdesc property value not interpolated?
Salut Olivier!
Note project.description is the default value :-)
yes that is why I got crazy :P
Is-it an open source with this issue ?
Yes I just included it in the Onami parent on /trunk. If I launch
`mvn install site`
I got the following error
[INFO] --- maven-doap-plugin:1.1:generate (site) @ org.apache.onami.parent ---
[INFO] This project is an ASF project, ASF Extensions to DOAP will be added.
[INFO] Generating an ASF DOAP file
/Users/stripodi/Documents/apache-workspace/onami/trunk/parent/target/site/doap.rdf
[ERROR]
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by ASF.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the plugin documentation:
[ERROR]
http://maven.apache.org/plugins/maven-doap-plugin/usage.html#DOAP_ASF_Configuration
Any idea?
TIA, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jan 7, 2013 at 9:52 PM, Olivier Lamy ol...@apache.org wrote:
Hi Simo,
I just changed an it with that and cannot reproduce.
2013/1/7 Simone Tripodi simonetrip...@apache.org:
Hi mates,
forwarding to dev@ - is that a bug?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-- Forwarded message --
From: Simone Tripodi simonetrip...@apache.org
Date: Sun, Jan 6, 2013 at 8:41 PM
Subject: [doap-plugin] shortdesc property value not interpolated?
To: Maven Users List us...@maven.apache.org
Hi all guys,
I am tryin' to plug the doap-plugin in Apache Onami and I noticed a
strange behaviour of the `shotdesc` property.
If not specified, the plugin terminates with an error:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I specify as
doapOptions
shortdesc${project.description}/shortdesc
/doapOptions
it terminates with the same error message:
[ERROR] A doapOptionsshortdesc//doapOptions parameter is required by
ASF.
If I set a value, such as
doapOptions
shortdescBazinga!/shortdesc
/doapOptions
It goes ok.
Ah, and yes, the ${project.description} property is specified :)
Is there something I overlooked or maybe a known issue?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Followup: use the #evaluate Velocity macro in the skin Velocity emplate
Hi all guys, I invested some time on trying the upgrade and I miserably failed :( The fact is that I didn't get explicit warnings/errors, the macro was simply ignored and rendered as #evaluate String, with arguments. Can someone please, with more doxia background, help me on give a try? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 29, 2012 at 8:15 AM, Lukas Theussl ltheu...@apache.org wrote: FYI: I've had troubles trying to upgrade velocity beyond version 1.5: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 IIRC, the main problem was backward compatibility. It should be ok with current skin versions but that's not tested. HTH, -Lukas Hervé BOUTEMY wrote: Hi Simone, Velocity is a direct dependency of doxia-site-renderer [2] and maven- reporting-exec [3] and ultimately of maven-site-plugin. I had a look at m-site-p trunk sources and actual Velocity version is 1.5. For immediate tests, you can try to override Velocity dependency in your pom's m-site-p plugin configuration. And later, add a Jira issue and change dependency in m-site-p trunk if you know Velocity well and are sure this won't break actual user sites (using Velocity 1.5 implicitely). I added explicit Velocity version in r1378417. Regards, Hervé [2] http://maven.apache.org/doxia/doxia-sitetools/index.html [3] http://maven.apache.org/shared/maven-reporting-exec/ Le mardi 28 aoűt 2012 14:02:12 Simone Tripodi a écrit : Hi all guys, as per subject, before cutting the current fluido RC, Robert and I gave some tries to evaluate strings inside the skin template using the #evaluate Velocity macro[1] but with no success... I guess mainly because the used velocity engine is a previous version which doesn't support that yet, but my question is if someone can point me to the direction on how I can provide my help on performing that upgrade. TIA, all the best! -Simo [1] http://velocity.apache.org/engine/devel/vtl-reference-guide.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: [VOTE] Maven Skins parent 7 and Maven Fluido skin 1.3.0
+1!!! thanks, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Aug 27, 2012 at 3:13 PM, Olivier Lamy ol...@apache.org wrote: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18713 Staging repo: https://repository.apache.org/content/repositories/maven-015/ Staging site: http://maven.apache.org/skins/maven-fluido-skin-1.3.0/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1375838 - in /maven/skins/trunk: maven-fluido-skin/pom.xml maven-skins/pom.xml
Salut mon ami, +++ maven/skins/trunk/maven-fluido-skin/pom.xml Tue Aug 21 22:49:07 2012 @@ -21,7 +21,7 @@ parent groupIdorg.apache.maven.skins/groupId artifactIdmaven-skins/artifactId -version6/version +version7-SNAPSHOT/version relativePath../maven-skins/pom.xml/relativePath /parent should that drive us on releasing the maven-skins:7 parent first? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1375838 - in /maven/skins/trunk: maven-fluido-skin/pom.xml maven-skins/pom.xml
Cool! :) can you wait me this WE to have a review to fluido, first? I stumbled in a couple of troubles and I would like to verify they are bugs or features :P TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 22, 2012 at 8:29 AM, Olivier Lamy ol...@apache.org wrote: 2012/8/22 Simone Tripodi simonetrip...@apache.org: Salut mon ami, +++ maven/skins/trunk/maven-fluido-skin/pom.xml Tue Aug 21 22:49:07 2012 @@ -21,7 +21,7 @@ parent groupIdorg.apache.maven.skins/groupId artifactIdmaven-skins/artifactId -version6/version +version7-SNAPSHOT/version relativePath../maven-skins/pom.xml/relativePath /parent should that drive us on releasing the maven-skins:7 parent first? My plan was to release both together :-) TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[fluido] versioning the produced css/js
Hi all guys,
time ago Robert and I were discussing about versioning the produced
minified css/js to avoid browser cache conflicts, I mean, ATM all
fluido skin versions refer to
$relativePath/js/apache-maven-fluido.min.js
$relativePath/js/apache-maven-fluido.min.cs
that could cheat users when upgrading skins, since they could have
been cached by the browser and while rendering the site, the old
css/js could be used.
I think it would be good versioning the produced resources according
to the current fluido skin version, such as
$relativePath/js/apache-maven-fluido-${project.version}.min.js
$relativePath/js/apache-maven-fluido-${project.version}.min.cs
WDYT?
TIA and all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [fluido] versioning the produced css/js
Thanks for the feedbacks guys, I just quickly took care about it, see MSKINS-61
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Aug 22, 2012 at 1:29 PM, Tony Chemit che...@codelutin.com wrote:
On Wed, 22 Aug 2012 13:22:56 +0200
Olivier Lamy ol...@apache.org wrote:
2012/8/22 Simone Tripodi simonetrip...@apache.org:
Hi all guys,
time ago Robert and I were discussing about versioning the produced
minified css/js to avoid browser cache conflicts, I mean, ATM all
fluido skin versions refer to
$relativePath/js/apache-maven-fluido.min.js
$relativePath/js/apache-maven-fluido.min.cs
that could cheat users when upgrading skins, since they could have
been cached by the browser and while rendering the site, the old
css/js could be used.
I think it would be good versioning the produced resources according
to the current fluido skin version, such as
$relativePath/js/apache-maven-fluido-${project.version}.min.js
$relativePath/js/apache-maven-fluido-${project.version}.min.cs
WDYT?
Definitely +1 !
+1
yes, as anything in life, versioning is a requirement (when two versions can
exist :)).
tony.
-
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: [fluido] Upgrading JQuery from 1.7.1 to 1.8.0
Good to know and thanks a lot for the quick reply Olivier! So, I am going to update JQuery in fluido - I honestly already prepared the update in case of positive reply, I just need to commit it :P Merci, a trés bientôt, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 22, 2012 at 2:40 PM, Olivier Lamy ol...@apache.org wrote: 2012/8/22 Simone Tripodi simonetrip...@apache.org: Hi all guys, are you aware of any side effect we could have if upgrading JQuery from 1.7.1 to 1.8.0 in fluido? Nope :-) I upgraded a project to bootstrap 2.1.0 and jQuery 1.8.0 and no issues (issues are with jqueryui) TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[DISCUSS] releasing Maven Maven Project Info Reports Plugin 2.5.1
Salut Hervé, this morning I received a JIRA notification on MPIR-236 where the user reported a broken property in the new report - I already fixed it on trunk, see r1369732, but I'd suggest to release a bugfix release, maybe 2.5.1 would fit... WDYT? best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Aug 5, 2012 at 9:48 AM, Hervé Boutemy hbout...@apache.org wrote: The Maven team is pleased to announce the release of the Maven Project Info Reports Plugin, version 2.5 The Maven Project Info Reports Plugin is a plugin that generates standard reports for the specified project. http://maven.apache.org/plugins/maven-project-info-reports-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.5/version /plugin Release Notes - Maven Project Info Reports Plugin - Version 2.5 Bug * [MPIR-245] blacklisted column in dependencies location is rendered without header * [MPIR-244] With Maven 3, Dependency Repository Locations in dependencies report shows my local repository manager id and url instead of public repository info * [MPIR-237] Unexpected download * [MPIR-228] HTML code detection in license content too precise: doesn't detect EPL at http://www.eclipse.org/legal/epl-v10.html is HTML Improvement * [MPIR-236] Create a new report to show how to include the module in different build systems New Feature * [MPIR-227] add an index listing all licenses at page start Task * [MPIR-246] use maven-plugin-tools' java 5 annotations Enjoy, -The Maven team - 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
[RESULT] Release Maven Fluido skin 1.2.2
Hi all mates, more than 72h have passed and this current [VOTE] thread can be considered completed and passes with the following resolution four +1 binding votes from following PMCs: * Robert Scholte * Olivier Lamy * Hervé BOUTEMY * Dennis Lundberg two +1 non-binding votes: * Tony Chemit * Mirko Friedenhagen no other votes have been casted. I'm proceeding on closing the repo on Nexus and redeploy the site. Thanks a lot for taking part to the review, have a nice day, all the best!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jul 6, 2012 at 10:26 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all Maven people, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2.2 We solved 11 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18392 There are still three issues in JIRA related to fluido: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-036/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for at least 72 hours and will close on Mon 9th at 8:30pm GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Fluido skin 1.2.2
Hi all Maven people, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2.2 We solved 11 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18392 There are still three issues in JIRA related to fluido: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-036/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for at least 72 hours and will close on Mon 9th at 8:30pm GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Doxia version 1.3
+1 (non binding) thanks a lot for the Doxia updates! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Apr 12, 2012 at 8:10 PM, Dennis Lundberg denn...@apache.org wrote: +1 from me On 2012-04-10 18:56, Dennis Lundberg wrote: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10780styleName=Htmlversion=17336 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=10780status=1 Staging repo: https://repository.apache.org/content/repositories/maven-031/ Staging site: http://maven.apache.org/doxia/doxia-1.3/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANNOUNCE] Maven Fluido Skin 1.2.1 is out!
Hi all, the Apache Maven team is happy to announce the release of Apache Maven Fluido Skin 1.2.1 The Apache Maven Fluido Skin is an Apache Maven site skin built on top of Twitter's bootstrap and other nice widgets. Follow below the list of resolved issues: Bugs [MSKINS-21] - Invalid text highlighting of license [MSKINS-38] - Tables in Bootstrap-2.0 are not backwards compatible Improvements [MSKINS-37] - Add(name and) version of used skin as comment in the page-header More details how to integrate the skin in your Apache projects can be found on the skin homepage http://maven.apache.org/skins/maven-fluido-skin/ Enjoy and have fun! -Simo, on behalf of the Apache Maven team. PS: sorry for the late message but I haven't had internet connection for few days http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT][VOTE] Release Apache Maven Fluido Skin 1.2.1 based on RC1
Hi all!!! more than 72h have passed and I consider this VOTE closed and passed with the following resolution: four +1 binding votes: * Olivier Lamy * Robert Scholte * Hervé BOUTEMY * Emmanuel Venisse one +1 non-biding vote: * Tony Chemit no other votes were casted. I am going to close the staging repository on Nexus and redeploy the site. Thanks a lot everybody who took part to the review process!!! All the best, have a nice weekend, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Mar 28, 2012 at 11:51 AM, Emmanuel Venisse emmanuel.veni...@gmail.com wrote: +1 Emmanuel On Tue, Mar 27, 2012 at 10:01 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all guys, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2.1, based on RC1 We solved 3 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18380 where [MSKINS-38] is the major issue that drove the new RC There are three new issues in JIRA related to fluido: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-118/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for 72 hours and will close ~on Fri 30th at 10:00am GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Fluido Skin 1.2.1 based on RC1
Salut Hervé! indeed, looks like the upgrade to Bootstrap2 is not painless as I originally thought - anyway, I'll try as much as I can to follow the release early often mantra :) All the best and thanks a lot everybody for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Mar 28, 2012 at 6:56 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 notice I just created MSKINS-40: not really critical, should not block this release since the table issue is really too much, but annoying Regards, Hervé Le mardi 27 mars 2012 10:01:16 Simone Tripodi a écrit : Hi all guys, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2.1, based on RC1 We solved 3 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName= Htmlversion=18380 where [MSKINS-38] is the major issue that drove the new RC There are three new issues in JIRA related to fluido: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430sta tus=1 Staging repo: https://repository.apache.org/content/repositories/maven-118/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for 72 hours and will close ~on Fri 30th at 10:00am GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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
[VOTE] Release Apache Maven Fluido Skin 1.2.1 based on RC1
Hi all guys, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2.1, based on RC1 We solved 3 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18380 where [MSKINS-38] is the major issue that drove the new RC There are three new issues in JIRA related to fluido: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-118/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for 72 hours and will close ~on Fri 30th at 10:00am GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Fluido Skin 1.2.1 based on RC1
Hi Jesse!! Breadcrumbs usually are defined inside the breadcrumbs element in site.xml: in the case of the fluido skin site, they are defined in the skin parent site descriptor[1] that are merged with the ones of maven parent and then inherited via menu ref=parent/. A little complex chain. Anyway, if you need to define breadcrumbs, just deine them and they should appear :P HTH, have a nice day! -Simo [1] https://svn.apache.org/repos/asf/maven/skins/trunk/maven-skins/src/site/site.xml http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 27, 2012 at 3:01 PM, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Mar 27, 2012 at 4:01 AM, Simone Tripodi simonetrip...@apache.org wrote: Staging repo: https://repository.apache.org/content/repositories/maven-118/ I'm using topbar and sidebar basic menus, but I'm not seeing any bread crumbs being created in the little area underneath the left and right nav areas. I do see the last publish date and project version, but no bread crumbs. Must I take an explicit action to get them displayed? I don't see anything special in http://svn.apache.org/viewvc/maven/skins/tags/maven-fluido-skin-1.2.1/src/site/site.xml?revision=1305760view=markup -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - 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: svn commit: r1304778 - in /maven/skins/trunk/maven-fluido-skin: pom.xml src/main/resources/META-INF/maven/site.vm
yeah, this rock!!! great! :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Mar 24, 2012 at 1:09 PM, rfscho...@apache.org wrote: Author: rfscholte Date: Sat Mar 24 12:09:17 2012 New Revision: 1304778 URL: http://svn.apache.org/viewvc?rev=1304778view=rev Log: Fix MSKINS-37: Add skin-version to template Modified: maven/skins/trunk/maven-fluido-skin/pom.xml maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm Modified: maven/skins/trunk/maven-fluido-skin/pom.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/pom.xml?rev=1304778r1=1304777r2=1304778view=diff == --- maven/skins/trunk/maven-fluido-skin/pom.xml (original) +++ maven/skins/trunk/maven-fluido-skin/pom.xml Sat Mar 24 12:09:17 2012 @@ -86,6 +86,7 @@ excludecss/**/exclude excludejs/**/exclude /excludes + filteringtrue/filtering !-- add skin-info -- /resource !-- include the print.css -- @@ -108,6 +109,16 @@ plugins plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-resources-plugin/artifactId + configuration + delimiters + delimiter@/delimiter + /delimiters + useDefaultDelimitersfalse/useDefaultDelimiters + /configuration + /plugin + plugin groupIdcom.samaxes.maven/groupId artifactIdmaven-minify-plugin/artifactId version1.3.5/version Modified: maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm?rev=1304778r1=1304777r2=1304778view=diff == --- maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm (original) +++ maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm Sat Mar 24 12:09:17 2012 @@ -1,7 +1,7 @@ !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; !-- | Generated by Apache Maven Doxia at $dateFormat.format( $currentDate ) - | Rendered using Apache Maven Fluido Skin + | Rendered using Apache Maven Fluido Skin @project.version@ -- #macro ( topMenu $menus ) #foreach( $menu in $menus ) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT][VOTE] Release Apache Maven Fluido Skin 1.2 based on RC1
Good morning all, more than 72 hours have passed so I consider this vote closed and concluded with the following resolution: five +1 binding votes: * Emmanuel Venisse * Robert Scholte * Stephen Connolly * Olivier Lamy * Herve Boutemy one +1 non-binding vote * Tony Chemit no other votes were casted. I'm going to promote the staged artifacts and update the skins and fluido-skin sites. Please click on G+1 and/or FB like as soon as you see the new site online! :) Thanks a lot everybody who took part to the review, all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 20, 2012 at 1:11 PM, herve.bout...@free.fr herve.bout...@free.fr wrote: +1 Envoyé depuis mon mobile - Reply message - De : Simone Tripodi simonetrip...@apache.org Pour : Maven Developers List dev@maven.apache.org Objet : [VOTE] Release Apache Maven Fluido Skin 1.2 based on RC1 Date : lun., mars 19, 2012 11:18 Hi all guys, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2, based on RC1 We solved 7 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18296 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-090/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for 72 hours and will close ~on Thru 22th at 10:30am GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANNOUNCE] Apache Maven Fluido Skin 1.2 is out
Hi all,
the Apache Maven team is happy to announce the release of Apache Maven
Fluido Skin 1.2
The Apache Maven Fluido Skin is an Apache Maven site skin built on top
of Twitter's bootstrap and other nice widgets. The main news of the
current release is the upgrade to Twitter Bootstrap 2 and the
integration of social networks share buttons, such as Facebook and G+.
Follow belo the list of resolved issues:
Bug
[MSKINS-26] - hard coded style with padding-top for body
[MSKINS-31] - If you have no body you get error on rendering
Improvement
[MSKINS-32] - Use ${project.name} as default for bannerLeft
New Feature
[MSKINS-29] - upgrade to bootstrap 2.0.0
[MSKINS-33] - Add Facebook like button integration
[MSKINS-34] - Add google +1 button support
Wish
[MSKINS-28] - Make it possible to center powered by logos in sidebar
More details how to integrate the skin in your Apache projects can be
found on the skin homepage
http://maven.apache.org/skins/maven-fluido-skin/
Enjoy and have fun!
-Simo, on behalf of the Apache Maven team.
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven Fluido Skin 1.2 based on RC1
Hi all guys, I'm opening a thread vote today for releasing Apache Maven Fluido Skin 1.2, based on RC1 We solved 7 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430styleName=Htmlversion=18296 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11430status=1 Staging repo: https://repository.apache.org/content/repositories/maven-090/ Staging site (not synched yet at the time of writing): http://maven.apache.org/skins/maven-fluido-skin-1.2/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote will stay open for 72 hours and will close ~on Thru 22th at 10:30am GMT. Please PMCs cast your votes! Many thanks in advance, all the best, -Simo [ ] +1 let's get it rmblee! [ ] +0 fine, but... [ ] -1 nope, because... http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: sandbox request
Bonjour Hervé! thanks for your feedbacks! I am going to open the sandbox, everybody's welcome on joining me on this! All the best, a trés bientôt, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Mar 10, 2012 at 9:29 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: great idea: go, go, go! sandbox is here to be flexible, don't hesitate to try anything here, no need for a vote or anything formal Of course, discussion is good to let people what is the purpose of anything new, to attract more people and ease later move out of sandbox. Regards, Hervé Le samedi 10 mars 2012 08:43:10 Simone Tripodi a écrit : Hi all guys, I postponed a little on working on next version of fluido because wouldn't add nothing really new that actual skin doesn't already, but at Commons Emmanuel Bourg came up with the idea of doing something cool for javadoc... So, I would like to open a new sandbox - fluido-doc, maybe? :P - to provide an alternative javadoc style that could be easily plugged according to http://maven.apache.org/plugins/maven-javadoc-plugin/examples/stylesheet-c onfiguration.html. Any objection? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: sandbox request
Hi all! I have a first spike, you can browse it on http://people.apache.org/~simonetripodi/fluido-docs/ hope you like it! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Mar 10, 2012 at 1:11 PM, Simone Tripodi simonetrip...@apache.org wrote: Bonjour Hervé! thanks for your feedbacks! I am going to open the sandbox, everybody's welcome on joining me on this! All the best, a trés bientôt, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Mar 10, 2012 at 9:29 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: great idea: go, go, go! sandbox is here to be flexible, don't hesitate to try anything here, no need for a vote or anything formal Of course, discussion is good to let people what is the purpose of anything new, to attract more people and ease later move out of sandbox. Regards, Hervé Le samedi 10 mars 2012 08:43:10 Simone Tripodi a écrit : Hi all guys, I postponed a little on working on next version of fluido because wouldn't add nothing really new that actual skin doesn't already, but at Commons Emmanuel Bourg came up with the idea of doing something cool for javadoc... So, I would like to open a new sandbox - fluido-doc, maybe? :P - to provide an alternative javadoc style that could be easily plugged according to http://maven.apache.org/plugins/maven-javadoc-plugin/examples/stylesheet-c onfiguration.html. Any objection? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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
sandbox request
Hi all guys, I postponed a little on working on next version of fluido because wouldn't add nothing really new that actual skin doesn't already, but at Commons Emmanuel Bourg came up with the idea of doing something cool for javadoc... So, I would like to open a new sandbox - fluido-doc, maybe? :P - to provide an alternative javadoc style that could be easily plugged according to http://maven.apache.org/plugins/maven-javadoc-plugin/examples/stylesheet-configuration.html. Any objection? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Intent to release Doxia and Site Plugin
There were a couple of strange behavior I noticed while developing the fluido skin, I will be much more than pleased to provide my feedbacks during the RC. Thanks for the hard work, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Feb 29, 2012 at 11:49 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: done in r1295325 Le lundi 27 février 2012 22:20:19 Hervé BOUTEMY a écrit : anybody interested in adding Markdown to modules map [1]? Regards, Hervé [1] http://maven.apache.org/doxia/doxia/index.html Le dimanche 26 février 2012 00:47:19 Dennis Lundberg a écrit : Hi I've started planning for a release of Doxia and the Site Plugin. If anyone has issues they'd like to fix before this release now is the time to do it. Just let me know how much time you need. My main driver is to get the fix for MSITE-602 into a release so that we can start using it. That will make staging the sites for our releases less troublesome. Here is the current plan: - Release Doxia 1.3 (10 issues fixed) - Release Doxia Sitetools 1.3 (6 issues fixed) - Release Maven Site Plugin 2.4 (6 issues fixed) and retire the 2.x branch after that - Release Maven Reporting Exec 1.0.2 (1 issue fixed) - Release Maven Site Plugin 3.1 (11 of 17 currently scheduled issues fixed) Of the 6 open issues for Site Plugin 3.1 I think we should try to fix MSITE-610, which is a documentation issue. It's currently assigned to Olivier. I'm fine pushing the rest to a later version. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RESULT] [VOTE] Release Maven Eclipse Plugin version Y.Z
Hi Barrie! the version X.Y needed to be replaced as well :P At a first sight, it looked spam :D All the best, have a nice day, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Feb 14, 2012 at 4:02 AM, Barrie Treloar baerr...@gmail.com wrote: On Tue, Feb 14, 2012 at 12:46 PM, Barrie Treloar baerr...@gmail.com wrote: Hi, The vote has passed with the following result : +1 (binding): Barrie Treloar, Benson Margulies, Olivier Lamy, Hervé Boutemy +1 (non binding): Robert Scholte I will promote the artifacts to the central repo. Apologies for not replacing XXX with Eclipse in the subject - 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: svnpubsub as an initiative
I think that a plugin that does all that work, would definitively help -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 12, 2012 at 5:23 PM, Benson Margulies bimargul...@gmail.com wrote: There are many Apache projects using Maven for some or all of their websites, and I think it would be a good public service to smooth their path to the requirement to use svnpubsub. After a bit of discussion on the infra list, I can now describe one scheme and I'd like to see what we can do to support it. First, assume that the user is going to have svn 1.7 as a client. We're aiming at our fellow Apache developers; if infra recommends 1.7, we can in conscience aim at that. So, the drill is as follows: 1) svn co a tree from svn used to publish the site. 2) remove all the local files, leaving the metadata. 3) run the site plugin aiming at this location. 4) svn remove all files in the metadata now absent from the tree, add all new files. 5) Pause, optionally, for review. 6) commit. I was thinking that this could be expressed as a plugin with a couple of goals to add to the site lifecycle, combined with the plain old ordinary local file wagon. I wonder if the scm provider API is strong enough to handle step 4, or whether this has to be coded from scratch, or whether it's reasonable to imagine extending the scm provider API to go here. Thoughts? - 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
[fluido-skin] next fluido release roadmap - suggestions required
Hi all guys, looks like Twitter's folks released the v2.0 of Bootstrap, I would suggest to copy the current fluido trunk in a 1_X branch, and moving the fluido development to 2.0 version, upgrading Bootstrap. WDYT? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1236657 - /maven/shared/trunk/maven-reporting-impl/pom.xml
Salut Olivier, I don't know if you're running to have the maven-reporting released, but I just started the VOTE for commons-validator-1.4.0, it would be good including it once (and if) released :) All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jan 27, 2012 at 1:37 PM, ol...@apache.org wrote: Author: olamy Date: Fri Jan 27 12:37:58 2012 New Revision: 1236657 URL: http://svn.apache.org/viewvc?rev=1236657view=rev Log: [MSHARED-222] Update the dependency on commons-validator. Modified: maven/shared/trunk/maven-reporting-impl/pom.xml Modified: maven/shared/trunk/maven-reporting-impl/pom.xml URL: http://svn.apache.org/viewvc/maven/shared/trunk/maven-reporting-impl/pom.xml?rev=1236657r1=1236656r2=1236657view=diff == --- maven/shared/trunk/maven-reporting-impl/pom.xml (original) +++ maven/shared/trunk/maven-reporting-impl/pom.xml Fri Jan 27 12:37:58 2012 @@ -101,7 +101,7 @@ dependency groupIdcommons-validator/groupId artifactIdcommons-validator/artifactId - version1.2.0/version + version1.3.1/version /dependency dependency groupIdorg.codehaus.plexus/groupId - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANNOUNCEMENT] Maven Skins v6 have been released!
Hi all, The Apache Maven team is pleased to announce the release of Apache Skins v6, which include * Maven Application Skin 1.0 (http://maven.apache.org/skins/maven-application-skin/) * Maven Default Skin 1.1 (http://maven.apache.org/skins/maven-default-skin/) * Maven Classic Skin 1.1 (http://maven.apache.org/skins/maven-classic-skin/) * Maven Stylus Skin 1.4 (http://maven.apache.org/skins/maven-stylus-skin/) * Maven Fluido Skin 1.1 (http://maven.apache.org/skins/maven-fluido-skin/) Sites are up-to-date and artifacts are already available on Maven Central repo. Happy skinning!!! -Simo, on behalf of the Apache Maven team http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1234592 - /maven/site/trunk/src/site/apt/skins/index.apt
Meri beaucoup Hervé,
I (erroneously) looked for that page in the skins site, thought that
was page was removed :P
A bientot,
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 22, 2012 at 9:15 PM, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jan 22 20:15:18 2012
New Revision: 1234592
URL: http://svn.apache.org/viewvc?rev=1234592view=rev
Log:
skins released
Modified:
maven/site/trunk/src/site/apt/skins/index.apt
Modified: maven/site/trunk/src/site/apt/skins/index.apt
URL:
http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/skins/index.apt?rev=1234592r1=1234591r2=1234592view=diff
==
--- maven/site/trunk/src/site/apt/skins/index.apt (original)
+++ maven/site/trunk/src/site/apt/skins/index.apt Sun Jan 22 20:15:18 2012
@@ -3,7 +3,7 @@
-
Dennis Lundberg
-
- 2011-11-26
+ 2012-01-22
-
Skins
@@ -14,15 +14,15 @@ Skins
*---+--+--+
|| Skin ||
Version || Description
*---+--+--+
-| {{{/skins/maven-application-skin/} Maven Application Skin}} |
1.0-SNAPSHOT | A skin used by applications like Archiva and Continuum.
+| {{{/skins/maven-application-skin/} Maven Application Skin}} | 1.0
| A skin used by applications like Archiva and Continuum.
*---+--+--+
-| {{{/skins/maven-classic-skin/} Maven Classic Skin}} | 1.0
| This skin resembles the look of a site generated by Maven 1.
+| {{{/skins/maven-classic-skin/} Maven Classic Skin}} | 1.1
| This skin resembles the look of a site generated by Maven 1.
*---+--+--+
-| {{{/skins/maven-default-skin/} Maven Default Skin}} | 1.0
| You get this skin if you don't specify any skin.
+| {{{/skins/maven-default-skin/} Maven Default Skin}} | 1.1
| You get this skin if you don't specify any skin.
*---+--+--+
-| {{{/skins/maven-stylus-skin/} Maven Stylus Skin}} | 1.3
| The skin used for the website of Maven itself.
+| {{{/skins/maven-stylus-skin/} Maven Stylus Skin}} | 1.4
| The skin used for the website of Maven itself.
*---+--+--+
-| {{{/skins/maven-fluido-skin/} Maven Fluido Skin}} | 1.0
| Skin based on bootstrap css
+| {{{/skins/maven-fluido-skin/} Maven Fluido Skin}} | 1.1
| Skin based on bootstrap css
*---+--+--+
To use one of these skins in your project, you use the skin element
of the
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1234592 - /maven/site/trunk/src/site/apt/skins/index.apt
Bonjour Hervé!
I just raw his message, I'm going to redeploy the stylus site to fill the gap!
Thanks for your help, have a nice day,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 22, 2012 at 10:59 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
yeah, I know the structure can be hard to follow :)
Did you look at Mark Derricutt's remark about missing Stylus Skin's sample
site?
Regards,
Hervé
Le dimanche 22 janvier 2012 22:39:47 Simone Tripodi a écrit :
Meri beaucoup Hervé,
I (erroneously) looked for that page in the skins site, thought that
was page was removed :P
A bientot,
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 22, 2012 at 9:15 PM, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jan 22 20:15:18 2012
New Revision: 1234592
URL: http://svn.apache.org/viewvc?rev=1234592view=rev
Log:
skins released
Modified:
maven/site/trunk/src/site/apt/skins/index.apt
Modified: maven/site/trunk/src/site/apt/skins/index.apt
URL:
http://svn.apache.org/viewvc/maven/site/trunk/src/site/apt/skins/index.
apt?rev=1234592r1=1234591r2=1234592view=diff
===
=== --- maven/site/trunk/src/site/apt/skins/index.apt (original)
+++ maven/site/trunk/src/site/apt/skins/index.apt Sun Jan 22 20:15:18
2012 @@ -3,7 +3,7 @@
-
Dennis Lundberg
-
- 2011-11-26
+ 2012-01-22
-
Skins
@@ -14,15 +14,15 @@ Skins
*---+--
+--+ || Skin
|| Version || Description
*---+--
+--+ -| {{{/skins/maven-application-skin/}
Maven Application Skin}} | 1.0-SNAPSHOT | A skin used by
applications like Archiva and Continuum. +|
{{{/skins/maven-application-skin/} Maven Application Skin}} | 1.0
| A skin used by applications like Archiva and Continuum.
*---+--
+--+ -| {{{/skins/maven-classic-skin/}
Maven Classic Skin}} | 1.0 | This skin resembles
the look of a site generated by Maven 1. +|
{{{/skins/maven-classic-skin/} Maven Classic Skin}} | 1.1
| This skin resembles the look of a site generated by Maven 1.
*---+--
+--+ -| {{{/skins/maven-default-skin/}
Maven Default Skin}} | 1.0 | You get this skin
if you don't specify any skin. +| {{{/skins/maven-default-skin/}
Maven Default Skin}} | 1.1 | You get this skin
if you don't specify any skin.
*---+--
+--+ -| {{{/skins/maven-stylus-skin/}
Maven Stylus Skin}} | 1.3 | The skin used for
the website of Maven itself. +| {{{/skins/maven-stylus-skin/} Maven
Stylus Skin}} | 1.4 | The skin used for the
website of Maven itself.
*---+--
+--+ -| {{{/skins/maven-fluido-skin/}
Maven Fluido Skin}} | 1.0 | Skin based on
bootstrap css +| {{{/skins/maven-fluido-skin/} Maven Fluido
Skin}} | 1.1 | Skin based on bootstrap css
*---+--
+--+
To use one of these skins in your project, you use the skin
element of the
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT][VOTE] Release Maven Skins version 6 based on RC2
Hi all guys, 72hours have passed and I declare that VOTE closed and passed with following resolution: 5 +1 binding votes from: Robert Scholte Hervé BOUTEMY Stephen Connolly Kristian Rosenvold Olivier Lamy 1 +1 non-binding vote from Tony Chemit no other votes have been casted. I'm going to proceed on closing the staging repo on Nexus and redeploying the sites, then announcing. Thanks a lot to everybody who took part on reviewing, all the best- and have a nice weekend! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jan 20, 2012 at 9:25 AM, Olivier Lamy ol...@apache.org wrote: +1 2012/1/18 Simone Tripodi simonetrip...@apache.org: Hi all guys, I am here to propose the RC2 Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo: https://repository.apache.org/content/repositories/maven-090/ Staging sites: http://maven.apache.org/skins/maven-application-skin-1.0/ http://maven.apache.org/skins/maven-default-skin-1.1/ http://maven.apache.org/skins/maven-classic-skin-1.1/ http://maven.apache.org/skins/maven-stylus-skin-1.4/ http://maven.apache.org/skins/maven-fluido-skin-1.1/ Dank je wel once again to Robert Scholte and Dennis Lundberg for the priceless support! This vote is open for 72 hours and closes on January 21th, at ~8:50pm CET. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: deploy maven site on SVN
Hi Oleg!!! On the other hand - I remember trying to push the generated site directly to the svn using both wagon-svn and maven-svn-wagon and in the end I decided to generate the new site on the local filesystem instead and then manually checkout old site, overwrite it with the generated files and manually commit the modified version back. that is exactly what we do in Cocoon, it's not what I really like (because requires extra manual steps) but at least it should work :) All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 19, 2012 at 9:12 AM, Oleg Estekhin oleg.estek...@gmail.com wrote: Hi **shameless self-advertisement, sorry** You can try my com.google.code.maven-svn-wagon: maven-svn-wagon (dev site at http://code.google.com/p/maven-svn-wagon/, the artifact is available from the Central). In general it works just as the Kohsuke's org.jvnet.wagon-svn:wagon-svn, and it depends in the SVNKit too, but it should work just a little bit better. On the other hand - I remember trying to push the generated site directly to the svn using both wagon-svn and maven-svn-wagon and in the end I decided to generate the new site on the local filesystem instead and then manually checkout old site, overwrite it with the generated files and manually commit the modified version back. I don't remember right now what it was exactly that I did not liked when autodeploing the site directly to the svn, the only glitch I remember is that site goal generates some files with mixed ending style (both lf and crlf in some files, this glitch is still present) and if you have configured the svn:eol-style autoproperty for html files then it will break the build. -Исходное сообщение- From: Simone Tripodi Sent: Wednesday, January 18, 2012 11:39 AM To: Maven Developers List Subject: Re: deploy maven site on SVN Hi all! thanks for the feedbacks - we are using indeed the Kohsuke's wagon but to deploy to ASF svn space it takes almost 3secs/page (it could be an issue of my ADSL upload band) but since javadoc is really big, it takes too much time :( wagon-ssh is still the faster :) all the best, have a nice day! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 2:13 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if the deps are cat a/b i can see about getting kk to donate the code here... but i think it uses svnkit so probably out of luck. (kk is an asf committer on one of the commons projects, so cla on file) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jan 2012 00:27, Brett Porter br...@apache.org wrote: wagon-svn by Kohsuke is much faster, but both should work. Either way, I think the main thing we need to do is make sure repeated identical executions of the site don't change files needlessly, so that the upload is minimal. On 18/01/2012, at 7:04 AM, Olivier Lamy wrote: 2012/1/17 Simone Tripodi simonetrip...@apache.org: Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub At Apache Any23 we want to keep the mvn generated site for clear reasons - the problem is that using a 3rd part ftp-wagon the deploy procedure is slow and takes too much time :S Agree that wagon scm is slow (http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html) as it's a per file deploy/commit. Can you suggest us please an automated site-deploy procedure using mvn - that doesn't involve manual steps? A turnaround would be svn checking out the target dir, deploying the site there, then committing, but I don't think it is a friendly procedure... I don't see better solution :-( Many thanks in advance, all the best -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter
Re: deploy maven site on SVN
Hi all guys, just to let you know that today I moved the Apache Any23[1] site deploying to local FS directory and then manual commit. It took *more than two hours*, with the good business ADSL upload band at office ... :( Whatever solution we can adopt to deploy the site on svn, it takes too much time :( -Simo [1] https://svn.apache.org/repos/asf/incubator/any23/site/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 19, 2012 at 10:18 PM, Brett Porter br...@apache.org wrote: On 18/01/2012, at 7:59 PM, Arnaud Héritier wrote: Perhaps if the SCM was GIT instead of SVN it could be faster ? It's not a short term solution but it can be another reason to use Git ASAP. I think you misinterpreted a typo in Simone's email - it's the CMS, not the SCM. This isn't related to the SCM used by the project - infra are using svnpubsub to publish sites (which takes effect almost immediately, in comparison to the slow rsync process that we used to wait for). On 18/01/2012, at 8:19 PM, ant elder wrote: On Tue, Jan 17, 2012 at 5:32 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub Do you have any links to something that says that, I didn't think there were any Incubator rules about what poddlings must do for websites. http://www.apache.org/dev/project-site.html#svnpubsub Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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: [site] site.xml head/footer inheritance
Hi Lukas! thanks for your feedback, I'm filling the issue right now! All the best, have a nice day, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 8:49 AM, Lukas Theussl ltheu...@gmail.com wrote: A quick look at the source code shows that the footer is not taken care of in doxia-decoration-model's DefaultDecorationModelInheritanceAssembler. The footer was only introduced in the last doxia release and this was apparently overlooked. So the only thing to do is file an issue... :) -Lukas Simone Tripodi wrote: Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: [site] site.xml head/footer inheritance
Hi again, just to let you know the issue is DOXIASITETOOLS-65 Thanks a lot in advance for your help!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 9:31 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Lukas! thanks for your feedback, I'm filling the issue right now! All the best, have a nice day, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 8:49 AM, Lukas Theussl ltheu...@gmail.com wrote: A quick look at the source code shows that the footer is not taken care of in doxia-decoration-model's DefaultDecorationModelInheritanceAssembler. The footer was only introduced in the last doxia release and this was apparently overlooked. So the only thing to do is file an issue... :) -Lukas Simone Tripodi wrote: Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: deploy maven site on SVN
Salut Arnaud, yes via Git is fast, I am using the org.kathrynhuxtable.maven.wagon:wagon-gitsite and I can confirm it is faster than SVN! All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/1/18 Arnaud Héritier aherit...@gmail.com: Perhaps if the SCM was GIT instead of SVN it could be faster ? It's not a short term solution but it can be another reason to use Git ASAP. Arnaud On Wed, Jan 18, 2012 at 8:39 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all! thanks for the feedbacks - we are using indeed the Kohsuke's wagon but to deploy to ASF svn space it takes almost 3secs/page (it could be an issue of my ADSL upload band) but since javadoc is really big, it takes too much time :( wagon-ssh is still the faster :) all the best, have a nice day! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 2:13 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if the deps are cat a/b i can see about getting kk to donate the code here... but i think it uses svnkit so probably out of luck. (kk is an asf committer on one of the commons projects, so cla on file) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jan 2012 00:27, Brett Porter br...@apache.org wrote: wagon-svn by Kohsuke is much faster, but both should work. Either way, I think the main thing we need to do is make sure repeated identical executions of the site don't change files needlessly, so that the upload is minimal. On 18/01/2012, at 7:04 AM, Olivier Lamy wrote: 2012/1/17 Simone Tripodi simonetrip...@apache.org: Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub At Apache Any23 we want to keep the mvn generated site for clear reasons - the problem is that using a 3rd part ftp-wagon the deploy procedure is slow and takes too much time :S Agree that wagon scm is slow (http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html) as it's a per file deploy/commit. Can you suggest us please an automated site-deploy procedure using mvn - that doesn't involve manual steps? A turnaround would be svn checking out the target dir, deploying the site there, then committing, but I don't think it is a friendly procedure... I don't see better solution :-( Many thanks in advance, all the best -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: deploy maven site on SVN
Hi Ant :) I got a reply from danielsh on JIRA[1] that simpli didn't allow me publishing the site via scp. I would really appreciate if you could help me to fix the misunderstanding, if any!!! Thanks in advance, all the best! -Simo [1] https://issues.apache.org/jira/browse/INFRA-4329 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 10:19 AM, ant elder ant.el...@gmail.com wrote: On Tue, Jan 17, 2012 at 5:32 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub Do you have any links to something that says that, I didn't think there were any Incubator rules about what poddlings must do for websites. ...ant - 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
[VOTE] Release Maven Skins version 6 based on RC2
Hi all guys, I am here to propose the RC2 Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo: https://repository.apache.org/content/repositories/maven-090/ Staging sites: http://maven.apache.org/skins/maven-application-skin-1.0/ http://maven.apache.org/skins/maven-default-skin-1.1/ http://maven.apache.org/skins/maven-classic-skin-1.1/ http://maven.apache.org/skins/maven-stylus-skin-1.4/ http://maven.apache.org/skins/maven-fluido-skin-1.1/ Dank je wel once again to Robert Scholte and Dennis Lundberg for the priceless support! This vote is open for 72 hours and closes on January 21th, at ~8:50pm CET. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
deploy maven site on SVN
Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub At Apache Any23 we want to keep the mvn generated site for clear reasons - the problem is that using a 3rd part ftp-wagon the deploy procedure is slow and takes too much time :S Can you suggest us please an automated site-deploy procedure using mvn - that doesn't involve manual steps? A turnaround would be svn checking out the target dir, deploying the site there, then committing, but I don't think it is a friendly procedure... Many thanks in advance, all the best -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: deploy maven site on SVN
Hi all! thanks for the feedbacks - we are using indeed the Kohsuke's wagon but to deploy to ASF svn space it takes almost 3secs/page (it could be an issue of my ADSL upload band) but since javadoc is really big, it takes too much time :( wagon-ssh is still the faster :) all the best, have a nice day! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 18, 2012 at 2:13 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if the deps are cat a/b i can see about getting kk to donate the code here... but i think it uses svnkit so probably out of luck. (kk is an asf committer on one of the commons projects, so cla on file) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jan 2012 00:27, Brett Porter br...@apache.org wrote: wagon-svn by Kohsuke is much faster, but both should work. Either way, I think the main thing we need to do is make sure repeated identical executions of the site don't change files needlessly, so that the upload is minimal. On 18/01/2012, at 7:04 AM, Olivier Lamy wrote: 2012/1/17 Simone Tripodi simonetrip...@apache.org: Hi all guys, ASF requirements for new incubating podlings requires that sites are managed * via the SCM * via svnpubsub At Apache Any23 we want to keep the mvn generated site for clear reasons - the problem is that using a 3rd part ftp-wagon the deploy procedure is slow and takes too much time :S Agree that wagon scm is slow (http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html) as it's a per file deploy/commit. Can you suggest us please an automated site-deploy procedure using mvn - that doesn't involve manual steps? A turnaround would be svn checking out the target dir, deploying the site there, then committing, but I don't think it is a friendly procedure... I don't see better solution :-( Many thanks in advance, all the best -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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: [site] site.xml head/footer inheritance
ping. sorry guys but I really have the feel that skins release is taking too much time, if you could provide me some feedbacks I'll proceed to related actions. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Jan 16, 2012 at 5:16 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[site] site.xml head/footer inheritance
Hi all guys, I am having troubles with the skin (lst check before re-proposing the skins releases) and while trying to apply fluido on Apache Commons I noticed that, attaching a site.xml descriptor to a parent, while the body.head element is inherited from cildren, body.footer is not. Did I miss something or this is the right behavior? Is there something to set or I have to provide an additional feature to the skin? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Need translation help into French for PMD Plugin
and I am ready for Italian of course, if needed! all the best, TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 11, 2012 at 11:39 PM, Dennis Lundberg denn...@apache.org wrote: Thanks to both of you! On 2012-01-11 22:36, Robert Scholte wrote: I'll add a dutch translation for both reports too. By the way, it looks like some cpd-report properties have an incorrect value for report.cpd.cpdlink It refers to PMD instead of CPD, or am I missing something? -Robert On Wed, 11 Jan 2012 22:26:36 +0100, Olivier Lamy ol...@apache.org wrote: Hello, I think I can :-) 2012/1/11 Dennis Lundberg denn...@apache.org: Hi I'm preparing a release of maven-pmd-plugin, and when going through the code I found out that the French localization is only done for the PMD report, but not for the CPD report. It would be great if someone could add maven-pmd-plugin/src/main/resources/cpd-report_fr.properties and translate the 9 properties into French for the CPD report. -- Dennis Lundberg - 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 -- Dennis Lundberg - 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: svn commit: r1228958 - /maven/skins/trunk/maven-skins/pom.xml
Thanks both for the suggestions, really appreciated!!!
I'll try to cut a new RC ASAP - but if someone else feels pleased to
do it, I have no objections!
Thanks again, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Jan 9, 2012 at 10:24 PM, Dennis Lundberg denn...@apache.org wrote:
On 2012-01-09 21:56, Hervé BOUTEMY wrote:
I don't know precisely if the configuration of the release plugin will be ok
without the rc profile.
But with the stagingSiteURL configuration, you can run the Staging the
latest
documentation part of the standard plugin release process [1]:
cd target/checkout
mvn site site:stage-deploy -Preporting
But, this is where the bug in the Site Plugin kicks in, so that the
deployed staging site ends up in the wrong place.
Regards,
Hervé
[1] http://maven.apache.org/developers/release/maven-plugin-release.html
Le lundi 9 janvier 2012 08:23:35 Simone Tripodi a écrit :
Salut Hervé!
does it mean I can safety remove the `rc` profile for addressing sites
distribution management?
TIA, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 10:21 PM, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jan 8 21:21:42 2012
New Revision: 1228958
URL: http://svn.apache.org/viewvc?rev=1228958view=rev
Log:
configured maven-site-plugin's stagingSiteURL (like done in
maven-plugins parent pom)
Modified:
maven/skins/trunk/maven-skins/pom.xml
Modified: maven/skins/trunk/maven-skins/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-skins/pom.xml?rev=
1228958r1=1228957r2=1228958view=diff
===
=== --- maven/skins/trunk/maven-skins/pom.xml (original)
+++ maven/skins/trunk/maven-skins/pom.xml Sun Jan 8 21:21:42 2012
@@ -74,6 +74,12 @@ under the License.
goalsdeploy site-deploy/goals
/configuration
/plugin
+ plugin
+ artifactIdmaven-site-plugin/artifactId
+ configuration
+
stagingSiteURLscp://people.apache.org/www/maven.apache.org/skins/${p
roject.artifactId}-${project.version}/stagingSiteURL +
/configuration
+ /plugin
/plugins
/pluginManagement
/build
-
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
--
Dennis Lundberg
-
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: svn commit: r1229755 - /maven/release/trunk/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/AbstractReleaseMojo.java
Hi Robert!
+ for ( String providerType : providerImplementations.keySet() )
{
- String providerType = (String) i.next();
- String providerImplementation = (String)
providerImplementations.get( providerType );
+ String providerImplementation = providerImplementations.get(
providerType );
why not just iterating over providerImplementations.entrySet() ?
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1227844 - /maven/skins/trunk/pom.xml
OK, thanks for checking -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Jan 8, 2012 at 11:58 AM, Dennis Lundberg denn...@apache.org wrote: Hi After testing that it does not have any impact on the build, I have now removed the property. On 2012-01-07 21:04, Simone Tripodi wrote: Hi Dennis, I have to admit that I blindly copied it somewhere else... apologize! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jan 7, 2012 at 8:18 PM, Dennis Lundberg denn...@apache.org wrote: Hi Simone Can you explain some more why this is needed? SUREFIRE-300 was fixed 4 and a half years ago... On 2012-01-05 22:21, simonetrip...@apache.org wrote: Author: simonetripodi Date: Thu Jan 5 21:21:44 2012 New Revision: 1227844 URL: http://svn.apache.org/viewvc?rev=1227844view=rev Log: added workaround for SUREFIRE-300 Modified: maven/skins/trunk/pom.xml Modified: maven/skins/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1227844r1=1227843r2=1227844view=diff == --- maven/skins/trunk/pom.xml (original) +++ maven/skins/trunk/pom.xml Thu Jan 5 21:21:44 2012 @@ -66,6 +66,11 @@ under the License. /site /distributionManagement + !-- Workaround for SUREFIRE-300 -- + properties + maven.test.skiptrue/maven.test.skip + /properties + build pluginManagement plugins -- Dennis Lundberg - 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 -- Dennis Lundberg - 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: svn commit: r1228307 - /maven/skins/trunk/pom.xml
Hi Dennis,
yes my env is ok, what I forgot is enabling the apache-release (blush)!
Thanks for the reminder!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 12:03 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
Have you setup your development environment according to this?
http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env
Important for signing is that the apache-release profile is in there.
You can then test that everything is correct by following these steps:
http://www.apache.org/dev/publishing-maven-artifacts.html#test_you_settings
On 2012-01-07 21:07, Simone Tripodi wrote:
Hi Dennis!
unfortunately it din't work, I had to drop twice the staging repo
because .asc signatures were missing... :(
Do you have any idea why it can happen?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Jan 7, 2012 at 8:21 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
This is already taken care of in the apache-parent. It should not be
needed here also.
On 2012-01-06 18:57, simonetrip...@apache.org wrote:
Author: simonetripodi
Date: Fri Jan 6 17:57:40 2012
New Revision: 1228307
URL: http://svn.apache.org/viewvc?rev=1228307view=rev
Log:
included gpg to sign artifacts while deploying a RC
Modified:
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1228307r1=1228306r2=1228307view=diff
==
--- maven/skins/trunk/pom.xml (original)
+++ maven/skins/trunk/pom.xml Fri Jan 6 17:57:40 2012
@@ -93,6 +93,23 @@ under the License.
properties
site.destination${project.artifactId}-${project.version}/site.destination
/properties
+ build
+ plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-gpg-plugin/artifactId
+ executions
+ execution
+ idsign-artifacts/id
+ phaseverify/phase
+ goals
+ goalsign/goal
+ /goals
+ /execution
+ /executions
+ /plugin
+ /plugins
+ /build
/profile
/profiles
--
Dennis Lundberg
-
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
--
Dennis Lundberg
-
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: [VOTE] Release Maven Skins version 6
Hi Dennis! thanks for your help, very appreciated! Do we have to cancel the actual vote, then cutting a new RC? Thanks again, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Jan 8, 2012 at 12:18 PM, Dennis Lundberg denn...@apache.org wrote: Hi Simone! I have split up the parent POM into two separate POMs now. Jenkins is happy about it :) The process for releasing more than one skin in the same release vote would look something like this: 1. Release maven-skins (the parent) Important: do not close the staging are in Nexus! 2. Release skin A Important: do not close the staging are in Nexus! 3. Release skin B Important: do not close the staging are in Nexus! . repeat for as many skins as you want to release . N. Close the staging area in Nexus On 2012-01-07 21:03, Simone Tripodi wrote: Hi Dennis! I thought it would have been releasing all skins in one shot since Robert (especially) and I fixed issues that affected all skins, I completely agree anyway about your considerations on SVN tags - any idea how to fix current situation? I would be glad to work on it! Thanks for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jan 7, 2012 at 8:15 PM, Dennis Lundberg denn...@apache.org wrote: Hi Simone Thanks for your efforts on the new Fluido Skin. We have not released all the skins together like this before. A skin release is like a plugin release, it's done once for each skin. Then there is the skin-parent which also has it's own release cycle. When I look in SVN for skins: http://svn.apache.org/viewvc/maven/skins/tags/ I only see one tag for all of the releases you propose, skins-6. In your case it does seem that all skins have had changes since their last respective release, but that is usually not the case. This will mean that it is very difficult to find the tag for a particular release of say the Fluido skin. How do I know that Fluido Skin 1.1 is in Skins 6, just by looking in SVN? It would still be possible to release all skins in one vote, by using the same staging area in Nexus for all of them, including the release of the skins parent. However I feel strongly that each released skin should have its own tag in SVN. So I'm -1 on the vote for now. We should probably change the skins-parent to something like we have for plugins, for this reason. One parent, which is used to inherit common configuration from and then another aggregator-pom that can be used to build all skins together in a CI-environment. At present these two functions are the same POM. On 2012-01-06 21:50, Simone Tripodi wrote: Hi all guys, I am here to propose the Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo:https://repository.apache.org/content/repositories/maven-024/ Staging sites:http://maven.apache.org/skins/maven-application-skin-1.0/http://maven.apache.org/skins/maven-default-skin-1.1/http://maven.apache.org/skins/maven-classic-skin-1.1/http://maven.apache.org/skins/maven-stylus-skin-1.4/http://maven.apache.org/skins/maven-fluido-skin-1.1/ A special acknowledgment goes to Robert Scholte who provided a priceless support. Dank je wel! Vote open for 72 hours and closes on January 9th, at ~8:45pm CET. [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release it because Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr
[CANCEL][VOTE] Release Maven Skins version 6
Hi all guys! the current vote is intended cancelled per Dennis consideration - and thanks for reviewing! I am going to to drop the current tag/Nesus artifacts and cut a new RC ASAP! Thanks all which take part to the review process and have a nice Sunday!!! all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jan 6, 2012 at 9:50 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I am here to propose the Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo:https://repository.apache.org/content/repositories/maven-024/ Staging sites:http://maven.apache.org/skins/maven-application-skin-1.0/http://maven.apache.org/skins/maven-default-skin-1.1/http://maven.apache.org/skins/maven-classic-skin-1.1/http://maven.apache.org/skins/maven-stylus-skin-1.4/http://maven.apache.org/skins/maven-fluido-skin-1.1/ A special acknowledgment goes to Robert Scholte who provided a priceless support. Dank je wel! Vote open for 72 hours and closes on January 9th, at ~8:45pm CET. [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release it because Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1228307 - /maven/skins/trunk/pom.xml
Hi Dennis,
how do you manage it? I would not having it turned on by default in my
settings.xml because I use the same laptop also for work/contribute to
other communities...
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 6:51 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
Hmm, when you do a release build, you should not have to enable the
apache-release profile. It should be enabled automatically.
On 2012-01-08 12:31, Simone Tripodi wrote:
Hi Dennis,
yes my env is ok, what I forgot is enabling the apache-release (blush)!
Thanks for the reminder!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 12:03 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
Have you setup your development environment according to this?
http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env
Important for signing is that the apache-release profile is in there.
You can then test that everything is correct by following these steps:
http://www.apache.org/dev/publishing-maven-artifacts.html#test_you_settings
On 2012-01-07 21:07, Simone Tripodi wrote:
Hi Dennis!
unfortunately it din't work, I had to drop twice the staging repo
because .asc signatures were missing... :(
Do you have any idea why it can happen?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Jan 7, 2012 at 8:21 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
This is already taken care of in the apache-parent. It should not be
needed here also.
On 2012-01-06 18:57, simonetrip...@apache.org wrote:
Author: simonetripodi
Date: Fri Jan 6 17:57:40 2012
New Revision: 1228307
URL: http://svn.apache.org/viewvc?rev=1228307view=rev
Log:
included gpg to sign artifacts while deploying a RC
Modified:
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1228307r1=1228306r2=1228307view=diff
==
--- maven/skins/trunk/pom.xml (original)
+++ maven/skins/trunk/pom.xml Fri Jan 6 17:57:40 2012
@@ -93,6 +93,23 @@ under the License.
properties
site.destination${project.artifactId}-${project.version}/site.destination
/properties
+ build
+ plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-gpg-plugin/artifactId
+ executions
+ execution
+ idsign-artifacts/id
+ phaseverify/phase
+ goals
+ goalsign/goal
+ /goals
+ /execution
+ /executions
+ /plugin
+ /plugins
+ /build
/profile
/profiles
--
Dennis Lundberg
-
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
--
Dennis Lundberg
-
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
--
Dennis Lundberg
-
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: svn commit: r1228307 - /maven/skins/trunk/pom.xml
Hi Dennis!
I am sure that is the reason, the arguments/ element is not merged :(
The reason why I applied that override is to avoid someone (myself at
first place :P) forgets to activate the required/needed profiles
during the release - especially because ITs sites are required to be
deployed, otherwise site links would be broken.
Do you have hints how to improve that? Many thanks in advance!!!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 9:15 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone,
The configuration for maven-release-plugin is in apache-parent:10
https://svn.apache.org/viewvc/maven/pom/tags/apache-10/pom.xml?view=markup
183 plugin
184 groupIdorg.apache.maven.plugins/groupId
185 artifactIdmaven-release-plugin/artifactId
186 version2.1/version
187 configuration
188 useReleaseProfilefalse/useReleaseProfile
189 goalsdeploy/goals
190 arguments-Papache-release/arguments
191 /configuration
192 /plugin
Perhaps because you had overridden the arguments configuration you
lost that profile?
On 2012-01-08 20:35, Simone Tripodi wrote:
Hi Dennis,
how do you manage it? I would not having it turned on by default in my
settings.xml because I use the same laptop also for work/contribute to
other communities...
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 6:51 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
Hmm, when you do a release build, you should not have to enable the
apache-release profile. It should be enabled automatically.
On 2012-01-08 12:31, Simone Tripodi wrote:
Hi Dennis,
yes my env is ok, what I forgot is enabling the apache-release (blush)!
Thanks for the reminder!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 12:03 PM, Dennis Lundberg denn...@apache.org
wrote:
Hi Simone
Have you setup your development environment according to this?
http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env
Important for signing is that the apache-release profile is in there.
You can then test that everything is correct by following these steps:
http://www.apache.org/dev/publishing-maven-artifacts.html#test_you_settings
On 2012-01-07 21:07, Simone Tripodi wrote:
Hi Dennis!
unfortunately it din't work, I had to drop twice the staging repo
because .asc signatures were missing... :(
Do you have any idea why it can happen?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Jan 7, 2012 at 8:21 PM, Dennis Lundberg denn...@apache.org
wrote:
Hi Simone
This is already taken care of in the apache-parent. It should not be
needed here also.
On 2012-01-06 18:57, simonetrip...@apache.org wrote:
Author: simonetripodi
Date: Fri Jan 6 17:57:40 2012
New Revision: 1228307
URL: http://svn.apache.org/viewvc?rev=1228307view=rev
Log:
included gpg to sign artifacts while deploying a RC
Modified:
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1228307r1=1228306r2=1228307view=diff
==
--- maven/skins/trunk/pom.xml (original)
+++ maven/skins/trunk/pom.xml Fri Jan 6 17:57:40 2012
@@ -93,6 +93,23 @@ under the License.
properties
site.destination${project.artifactId}-${project.version}/site.destination
/properties
+ build
+ plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-gpg-plugin/artifactId
+ executions
+ execution
+ idsign-artifacts/id
+ phaseverify/phase
+ goals
+ goalsign/goal
+ /goals
+ /execution
+ /executions
+ /plugin
+ /plugins
+ /build
/profile
/profiles
--
Dennis Lundberg
-
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
--
Dennis Lundberg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1228958 - /maven/skins/trunk/maven-skins/pom.xml
Salut Hervé!
does it mean I can safety remove the `rc` profile for addressing sites
distribution management?
TIA, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Jan 8, 2012 at 10:21 PM, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Jan 8 21:21:42 2012
New Revision: 1228958
URL: http://svn.apache.org/viewvc?rev=1228958view=rev
Log:
configured maven-site-plugin's stagingSiteURL (like done in maven-plugins
parent pom)
Modified:
maven/skins/trunk/maven-skins/pom.xml
Modified: maven/skins/trunk/maven-skins/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-skins/pom.xml?rev=1228958r1=1228957r2=1228958view=diff
==
--- maven/skins/trunk/maven-skins/pom.xml (original)
+++ maven/skins/trunk/maven-skins/pom.xml Sun Jan 8 21:21:42 2012
@@ -74,6 +74,12 @@ under the License.
goalsdeploy site-deploy/goals
/configuration
/plugin
+ plugin
+ artifactIdmaven-site-plugin/artifactId
+ configuration
+
stagingSiteURLscp://people.apache.org/www/maven.apache.org/skins/${project.artifactId}-${project.version}/stagingSiteURL
+ /configuration
+ /plugin
/plugins
/pluginManagement
/build
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven different java version
Hi manolakis, may you didn't set the JAVA_HOME env variable, I sugest you following the Installation Instructions[1], see the Unix-based Operating Systems (Linux, Solaris and Mac OS X) HTH, -Simo [1] http://maven.apache.org/download.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jan 6, 2012 at 8:32 PM, manolakis agnosto...@hotmail.com wrote: Hi there, I am totally newbie with Maven and I would appreciate some help. My problem is that mvn --version returns a totally different java version that java -version will return. Does anybody know how to fix this on a MAC computer. Thank you. -- View this message in context: http://maven.40175.n5.nabble.com/maven-different-java-version-tp5126440p5126440.html Sent from the Maven Developers mailing list archive at Nabble.com. - 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: [VOTE] Release Maven Skins version 6
How come the Sylus skin is called Site Skin on the Maven site? /Anders Hi Anders! there was a typo in the name/ element in the Stylus pom, it is now fixed on trunk! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Skins version 6
Hi Dennis! I thought it would have been releasing all skins in one shot since Robert (especially) and I fixed issues that affected all skins, I completely agree anyway about your considerations on SVN tags - any idea how to fix current situation? I would be glad to work on it! Thanks for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jan 7, 2012 at 8:15 PM, Dennis Lundberg denn...@apache.org wrote: Hi Simone Thanks for your efforts on the new Fluido Skin. We have not released all the skins together like this before. A skin release is like a plugin release, it's done once for each skin. Then there is the skin-parent which also has it's own release cycle. When I look in SVN for skins: http://svn.apache.org/viewvc/maven/skins/tags/ I only see one tag for all of the releases you propose, skins-6. In your case it does seem that all skins have had changes since their last respective release, but that is usually not the case. This will mean that it is very difficult to find the tag for a particular release of say the Fluido skin. How do I know that Fluido Skin 1.1 is in Skins 6, just by looking in SVN? It would still be possible to release all skins in one vote, by using the same staging area in Nexus for all of them, including the release of the skins parent. However I feel strongly that each released skin should have its own tag in SVN. So I'm -1 on the vote for now. We should probably change the skins-parent to something like we have for plugins, for this reason. One parent, which is used to inherit common configuration from and then another aggregator-pom that can be used to build all skins together in a CI-environment. At present these two functions are the same POM. On 2012-01-06 21:50, Simone Tripodi wrote: Hi all guys, I am here to propose the Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo:https://repository.apache.org/content/repositories/maven-024/ Staging sites:http://maven.apache.org/skins/maven-application-skin-1.0/http://maven.apache.org/skins/maven-default-skin-1.1/http://maven.apache.org/skins/maven-classic-skin-1.1/http://maven.apache.org/skins/maven-stylus-skin-1.4/http://maven.apache.org/skins/maven-fluido-skin-1.1/ A special acknowledgment goes to Robert Scholte who provided a priceless support. Dank je wel! Vote open for 72 hours and closes on January 9th, at ~8:45pm CET. [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release it because Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: svn commit: r1227844 - /maven/skins/trunk/pom.xml
Hi Dennis, I have to admit that I blindly copied it somewhere else... apologize! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jan 7, 2012 at 8:18 PM, Dennis Lundberg denn...@apache.org wrote: Hi Simone Can you explain some more why this is needed? SUREFIRE-300 was fixed 4 and a half years ago... On 2012-01-05 22:21, simonetrip...@apache.org wrote: Author: simonetripodi Date: Thu Jan 5 21:21:44 2012 New Revision: 1227844 URL: http://svn.apache.org/viewvc?rev=1227844view=rev Log: added workaround for SUREFIRE-300 Modified: maven/skins/trunk/pom.xml Modified: maven/skins/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1227844r1=1227843r2=1227844view=diff == --- maven/skins/trunk/pom.xml (original) +++ maven/skins/trunk/pom.xml Thu Jan 5 21:21:44 2012 @@ -66,6 +66,11 @@ under the License. /site /distributionManagement + !-- Workaround for SUREFIRE-300 -- + properties + maven.test.skiptrue/maven.test.skip + /properties + build pluginManagement plugins -- Dennis Lundberg - 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: svn commit: r1228307 - /maven/skins/trunk/pom.xml
Hi Dennis!
unfortunately it din't work, I had to drop twice the staging repo
because .asc signatures were missing... :(
Do you have any idea why it can happen?
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Jan 7, 2012 at 8:21 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
This is already taken care of in the apache-parent. It should not be
needed here also.
On 2012-01-06 18:57, simonetrip...@apache.org wrote:
Author: simonetripodi
Date: Fri Jan 6 17:57:40 2012
New Revision: 1228307
URL: http://svn.apache.org/viewvc?rev=1228307view=rev
Log:
included gpg to sign artifacts while deploying a RC
Modified:
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?rev=1228307r1=1228306r2=1228307view=diff
==
--- maven/skins/trunk/pom.xml (original)
+++ maven/skins/trunk/pom.xml Fri Jan 6 17:57:40 2012
@@ -93,6 +93,23 @@ under the License.
properties
site.destination${project.artifactId}-${project.version}/site.destination
/properties
+ build
+ plugins
+ plugin
+ groupIdorg.apache.maven.plugins/groupId
+ artifactIdmaven-gpg-plugin/artifactId
+ executions
+ execution
+ idsign-artifacts/id
+ phaseverify/phase
+ goals
+ goalsign/goal
+ /goals
+ /execution
+ /executions
+ /plugin
+ /plugins
+ /build
/profile
/profiles
--
Dennis Lundberg
-
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: svn commit: r1227893 - in /maven/skins/trunk: maven-application-skin/pom.xml maven-classic-skin/pom.xml maven-default-skin/pom.xml maven-fluido-skin/pom.xml maven-stylus-skin/pom.xml pom.xml
Hi Dennis!
yes please, it would be much more than appreciated, feel free to fix
stuff there if needed!
TIA!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Jan 7, 2012 at 8:26 PM, Dennis Lundberg denn...@apache.org wrote:
Hi Simone
I agree with Hervé, we already have a method for this that we use in
most of our sub-projects. That work in the same way as your method, but
it would be easier if ha only one way of doing it. I'd be happy to help
set it up.
On 2012-01-06 20:21, Simone Tripodi wrote:
Salut Hervé,
sorry but didn't notice earlier you replied to the commit!
At the end of the day I figured out how to deploy the staging site
directly to the required location, avoiding the auxiliary scp
invocation - that is simple approach based on a RC profile that allows
deploys all skins in one shot.
It just worked - I'm waiting for sites sync to open the VOTE thread -
hope that works for you as well, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 1:16 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
forgot the link...
[1] http://svn.apache.org/viewvc/maven/plugins/tags/maven-
plugins-22/pom.xml?view=markup
and the doc to staging release:
http://maven.apache.org/developers/release/maven-plugin-release.html
Le vendredi 6 janvier 2012 01:14:01 Hervé BOUTEMY a écrit :
Hi Simone,
The classical way to do such versioned + non-versioned site deployment is
by
using stagingSiteURL configuration in site plugin, see [1]
Then the release documentation explains how to stage the versionned doc
I suppose this is usable in this case, instead of this rc profile, no?
Regards,
Hervé
Le jeudi 5 janvier 2012 23:25:56 simonetrip...@apache.org a écrit :
Author: simonetripodi
Date: Thu Jan 5 23:25:56 2012
New Revision: 1227893
URL: http://svn.apache.org/viewvc?rev=1227893view=rev
Log:
allows dynamic URLs depending on the active profiles
Modified:
maven/skins/trunk/maven-application-skin/pom.xml
maven/skins/trunk/maven-classic-skin/pom.xml
maven/skins/trunk/maven-default-skin/pom.xml
maven/skins/trunk/maven-fluido-skin/pom.xml
maven/skins/trunk/maven-stylus-skin/pom.xml
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/maven-application-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-application-skin/po
m.x ml?rev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-application-skin/pom.xml (original)
+++ maven/skins/trunk/maven-application-skin/pom.xml Thu Jan 5
23:25:56 2012 @@ -33,7 +33,7 @@ under the License.
nameMaven Application Skin/name
descriptionMaven Application Skin/description
- urlhttp://maven.apache.org/skins/${project.artifactId}/url
+ urlhttp://maven.apache.org/skins/${site.destination}/url
issueManagement
systemjira/system
@@ -47,7 +47,7 @@ under the License.
!-- Cannot define in parent --
site
idapache.website/id
-
urlscp://people.apache.org/www/maven.apache.org/skins/${project.artifa
ctI d}-${project.version}/url +
urlscp://people.apache.org/www/maven.apache.org/skins/${site.destinati
on} /url /site
/distributionManagement
/profile
Modified: maven/skins/trunk/maven-classic-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-classic-skin/pom.xm
l?r ev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-classic-skin/pom.xml (original)
+++ maven/skins/trunk/maven-classic-skin/pom.xml Thu Jan 5 23:25:56
2012
@@ -33,7 +33,7 @@ under the License.
nameMaven Classic Skin/name
descriptionMaven Classic Skin/description
- urlhttp://maven.apache.org/skins/${project.artifactId}/url
+ urlhttp://maven.apache.org/skins/${site.destination}/url
issueManagement
systemjira/system
@@ -47,7 +47,7 @@ under the License.
!-- Cannot define in parent --
site
idapache.website/id
-
urlscp://people.apache.org/www/maven.apache.org/skins/${project.artifa
ctI d}-${project.version}/url +
urlscp://people.apache.org/www/maven.apache.org/skins/${site.destinati
on} /url /site
/distributionManagement
/profile
Modified: maven/skins/trunk/maven-default-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-default-skin/pom.xm
l?r ev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-default-skin/pom.xml (original)
+++ maven/skins/trunk/maven-default-skin/pom.xml Thu Jan 5 23:25:56
2012
@@ -33,7 +33,7
Re: svn commit: r1227893 - in /maven/skins/trunk: maven-application-skin/pom.xml maven-classic-skin/pom.xml maven-default-skin/pom.xml maven-fluido-skin/pom.xml maven-stylus-skin/pom.xml pom.xml
Salut Hervé,
sorry but didn't notice earlier you replied to the commit!
At the end of the day I figured out how to deploy the staging site
directly to the required location, avoiding the auxiliary scp
invocation - that is simple approach based on a RC profile that allows
deploys all skins in one shot.
It just worked - I'm waiting for sites sync to open the VOTE thread -
hope that works for you as well, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 1:16 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
forgot the link...
[1] http://svn.apache.org/viewvc/maven/plugins/tags/maven-
plugins-22/pom.xml?view=markup
and the doc to staging release:
http://maven.apache.org/developers/release/maven-plugin-release.html
Le vendredi 6 janvier 2012 01:14:01 Hervé BOUTEMY a écrit :
Hi Simone,
The classical way to do such versioned + non-versioned site deployment is by
using stagingSiteURL configuration in site plugin, see [1]
Then the release documentation explains how to stage the versionned doc
I suppose this is usable in this case, instead of this rc profile, no?
Regards,
Hervé
Le jeudi 5 janvier 2012 23:25:56 simonetrip...@apache.org a écrit :
Author: simonetripodi
Date: Thu Jan 5 23:25:56 2012
New Revision: 1227893
URL: http://svn.apache.org/viewvc?rev=1227893view=rev
Log:
allows dynamic URLs depending on the active profiles
Modified:
maven/skins/trunk/maven-application-skin/pom.xml
maven/skins/trunk/maven-classic-skin/pom.xml
maven/skins/trunk/maven-default-skin/pom.xml
maven/skins/trunk/maven-fluido-skin/pom.xml
maven/skins/trunk/maven-stylus-skin/pom.xml
maven/skins/trunk/pom.xml
Modified: maven/skins/trunk/maven-application-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-application-skin/po
m.x ml?rev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-application-skin/pom.xml (original)
+++ maven/skins/trunk/maven-application-skin/pom.xml Thu Jan 5
23:25:56 2012 @@ -33,7 +33,7 @@ under the License.
nameMaven Application Skin/name
descriptionMaven Application Skin/description
- urlhttp://maven.apache.org/skins/${project.artifactId}/url
+ urlhttp://maven.apache.org/skins/${site.destination}/url
issueManagement
systemjira/system
@@ -47,7 +47,7 @@ under the License.
!-- Cannot define in parent --
site
idapache.website/id
-
urlscp://people.apache.org/www/maven.apache.org/skins/${project.artifa
ctI d}-${project.version}/url +
urlscp://people.apache.org/www/maven.apache.org/skins/${site.destinati
on} /url /site
/distributionManagement
/profile
Modified: maven/skins/trunk/maven-classic-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-classic-skin/pom.xm
l?r ev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-classic-skin/pom.xml (original)
+++ maven/skins/trunk/maven-classic-skin/pom.xml Thu Jan 5 23:25:56
2012
@@ -33,7 +33,7 @@ under the License.
nameMaven Classic Skin/name
descriptionMaven Classic Skin/description
- urlhttp://maven.apache.org/skins/${project.artifactId}/url
+ urlhttp://maven.apache.org/skins/${site.destination}/url
issueManagement
systemjira/system
@@ -47,7 +47,7 @@ under the License.
!-- Cannot define in parent --
site
idapache.website/id
-
urlscp://people.apache.org/www/maven.apache.org/skins/${project.artifa
ctI d}-${project.version}/url +
urlscp://people.apache.org/www/maven.apache.org/skins/${site.destinati
on} /url /site
/distributionManagement
/profile
Modified: maven/skins/trunk/maven-default-skin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/skins/trunk/maven-default-skin/pom.xm
l?r ev=1227893r1=1227892r2=1227893view=diff
=== === --- maven/skins/trunk/maven-default-skin/pom.xml (original)
+++ maven/skins/trunk/maven-default-skin/pom.xml Thu Jan 5 23:25:56
2012
@@ -33,7 +33,7 @@ under the License.
nameMaven Default Skin/name
descriptionMaven Default Skin/description
- urlhttp://maven.apache.org/skins/${project.artifactId}/url
+ urlhttp://maven.apache.org/skins/${site.destination}/url
issueManagement
systemjira/system
@@ -47,7 +47,7 @@ under the License.
!-- Cannot define in parent --
site
idapache.website/id
-
urlscp://people.apache.org/www/maven.apache.org/skins/${project.artifa
ctI d}-${project.version}/url +
[VOTE] Release Maven Skins version 6
Hi all guys, I am here to propose the Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo:https://repository.apache.org/content/repositories/maven-024/ Staging sites:http://maven.apache.org/skins/maven-application-skin-1.0/http://maven.apache.org/skins/maven-default-skin-1.1/http://maven.apache.org/skins/maven-classic-skin-1.1/http://maven.apache.org/skins/maven-stylus-skin-1.4/http://maven.apache.org/skins/maven-fluido-skin-1.1/ A special acknowledgment goes to Robert Scholte who provided a priceless support. Dank je wel! Vote open for 72 hours and closes on January 9th, at ~8:45pm CET. [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release it because Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Skins version 6
apologize for the format but I don't know WHY gmail reformat plain text emails!!! http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jan 6, 2012 at 9:50 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I am here to propose the Maven Skins version 6, that includes * Maven Application Skin 1.0 * Maven Default Skin 1.1 * Maven Classic Skin 1.1 * Maven Stylus Skin 1.4 * Maven Fluido Skin 1.1 We solved 16 issues:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20fixVersion%20in%20(%22fluido-1.1%22,%20%22application-1.0%22,%20%22default-1.1%22,%20%22stylus-1.4%22,%20%22classic-1.1%22)%20ORDER%20BY%20component,%20key There is still one issues left in JIRA:http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project%20=%20MSKINS%20AND%20status%20=%20Open Staging repo:https://repository.apache.org/content/repositories/maven-024/ Staging sites:http://maven.apache.org/skins/maven-application-skin-1.0/http://maven.apache.org/skins/maven-default-skin-1.1/http://maven.apache.org/skins/maven-classic-skin-1.1/http://maven.apache.org/skins/maven-stylus-skin-1.4/http://maven.apache.org/skins/maven-fluido-skin-1.1/ A special acknowledgment goes to Robert Scholte who provided a priceless support. Dank je wel! Vote open for 72 hours and closes on January 9th, at ~8:45pm CET. [ ] +1 release it[ ] +0 go ahead I don't care[ ] -1 no, do not release it because Thanks in advance for reviewing! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[site] Managing multiple countries with same languages
Hi all guys, at MyBatis we are managing the site internationalization and we already have the Simplified Chinese translation; a users started contributing with Traditional Chinese, but found the issue I reported below... Can you give me some help please? Many thanks in advance, all the best wishes! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Dec 30, 2011 at 4:49 AM, Keith Wong wong...@gmail.com wrote: In fact, I've just started to translate the Traditional Chinese version. Once the SVN has the appropriate skeleton files, I could start to contribute. But it takes time to complete. However, I have encountered a problem in the maven-site-plugin plugin. It seems it could not handle multiple countries with the same language. In this case, the setting should be localesen,es,ja,zh_CN,zh_TW/locales. When the site is built, both zh_CN and zh_TW content goes into the zh directory. Maybe you guys could help for this. Keith - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [site] Managing multiple countries with same languages
Thanks a lot Dennis, I reported the bug in MSITE-626. best wishes!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Dec 30, 2011 at 8:40 PM, Dennis Lundberg denn...@apache.org wrote: Hi A quick check in the source code indicates that the Site Plugin only uses the language-part of the specified Locale. Can you please open an issue in JIRA for this? http://jira.codehaus.org/browse/MSITE On 2011-12-30 18:29, Simone Tripodi wrote: Hi all guys, at MyBatis we are managing the site internationalization and we already have the Simplified Chinese translation; a users started contributing with Traditional Chinese, but found the issue I reported below... Can you give me some help please? Many thanks in advance, all the best wishes! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Dec 30, 2011 at 4:49 AM, Keith Wong wong...@gmail.com wrote: In fact, I've just started to translate the Traditional Chinese version. Once the SVN has the appropriate skeleton files, I could start to contribute. But it takes time to complete. However, I have encountered a problem in the maven-site-plugin plugin. It seems it could not handle multiple countries with the same language. In this case, the setting should be localesen,es,ja,zh_CN,zh_TW/locales. When the site is built, both zh_CN and zh_TW content goes into the zh directory. Maybe you guys could help for this. Keith - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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
staging release site
Hi all guys! :) I intend to publish a [fluido] RC in a short while - can you tell me please what's the policy to publish staging sites? I would avoid to override the current site :P Many thanks in advance, have a nice day! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Using maven as appstore for java app
For what it worths, I totally agree :) I've been looking for ages for a Java solution that allows sharing libraries in applications and the Appassembler ATM makes me satisfied :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Dec 21, 2011 at 9:05 PM, Brett Porter br...@apache.org wrote: As Wayne suggested, you can use Maven to assemble and distribute an application. For a runtime, using a maven repository makes a lot of sense. I wouldn't use Maven itself for this, but Maven's libraries for interacting with a repository. This is being used in lots of other applications, for example: http://karaf.apache.org/manual/latest-2.2.x/users-guide/provisioning.html - Brett On 22/12/2011, at 1:28 AM, Deepesh Garg wrote: Hi, I was wondering if maven repository structure can be exploited to also distribute java applications. Same repository structure may be used on client side for installing and launching java apps. I see many benefit in doing so (cleaner application packaging, minimum download, standard directory structure, simple upgrade (much like Debian)). Are there any good reasons why maven should not be used as application installer and launcher? Or is it already done and I slept a bit too much. Deepesh -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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
pom.xml parser
Hi all guys, can you please point me to the pom.xml parser location on SVN? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: pom.xml parser
Merci Jeff and Julien, I'll have a deep look at it :) Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Dec 11, 2011 at 9:07 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, I think it is https://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-model/ (using modello). Regards, Julien - Mail original - De : Simone Tripodi simonetrip...@apache.org À : Maven Developers List dev@maven.apache.org Cc : Envoyé le : Dimanche 11 Décembre 2011 20h45 Objet : pom.xml parser Hi all guys, can you please point me to the pom.xml parser location on SVN? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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: svn commit: r1211624 - in /maven/skins/trunk/maven-fluido-skin/src: it/mskins-13/ it/mskins-13/pom.xml it/mskins-13/src/ it/mskins-13/src/site/ it/mskins-13/src/site/site.xml main/resources/META-I
Hello Robert! thanks for your enthusiasm on fluido! :) About the searchbar on top, I would like to reach that[1] rendering - I'll try to work on it tomorrow (today I'm off for the bigger part of the day) Thanks again! Simo [1] http://imageshack.us/f/17/screenshot20111208at848.png/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Dec 7, 2011 at 9:38 PM, rfscho...@apache.org wrote: Author: rfscholte Date: Wed Dec 7 20:38:48 2011 New Revision: 1211624 URL: http://svn.apache.org/viewvc?rev=1211624view=rev Log: MSKINS-13: change searchbutton in topbar. Better, but still not good enough Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/pom.xml maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/site.xml Modified: maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/pom.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/pom.xml?rev=1211624view=auto == --- maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/pom.xml (added) +++ maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/pom.xml Wed Dec 7 20:38:48 2011 @@ -0,0 +1,76 @@ +?xml version=1.0 encoding=UTF-8? +!-- + 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. +-- +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; + modelVersion4.0.0/modelVersion + + groupIdorg.apache.maven.skins.its/groupId + artifactIdmskins-13/artifactId + version1.0-SNAPSHOT/version + + properties + skinNameApache Maven Fluido Skin/skinName + skinDescriptionThe Apache Maven Fluido Skin is an Apache Maven site skin + built on top of Twitter's bootstrap./skinDescription + skinGroupIdorg.apache.maven.skins/skinGroupId + skinArtifactIdmaven-fluido-skin/skinArtifactId + skinVersion1.1-SNAPSHOT/skinVersion + /properties + + build + plugins + plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-site-plugin/artifactId + version3.0/version + /plugin + /plugins + /build + + reporting + plugins + plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-project-info-reports-plugin/artifactId + version2.4/version + configuration + dependencyDetailsEnabledfalse/dependencyDetailsEnabled + dependencyLocationsEnabledfalse/dependencyLocationsEnabled + /configuration + reportSets + reportSet + reports + reportindex/report + reportsummary/report + reportlicense/report + reportproject-team/report + reportscm/report + reportissue-tracking/report + reportmailing-list/report + reportdependencies/report + reportcim/report + reportplugin-management/report + reportplugins/report + /reports + /reportSet + /reportSets + /plugin + /plugins + /reporting + +/project \ No newline at end of file Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/site.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/site.xml?rev=1211624view=auto == --- maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/site.xml (added) +++ maven/skins/trunk/maven-fluido-skin/src/it/mskins-13/src/site/site.xml Wed Dec 7 20:38:48 2011 @@ -0,0 +1,43 @@ +?xml version=1.0 encoding=UTF-8? + +!-- +/* + * Licensed to the Apache Software
Re: svn commit: r1211230 - in /maven/skins/trunk/maven-fluido-skin/src: it/mskins-16/ it/mskins-16/pom.xml it/mskins-16/src/ it/mskins-16/src/site/ it/mskins-16/src/site/site.xml main/resources/META-I
nice, thanks for taking care Robert!!! is there anything more we missed before promoting a new release? many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Dec 7, 2011 at 12:42 AM, rfscho...@apache.org wrote: Author: rfscholte Date: Tue Dec 6 23:42:37 2011 New Revision: 1211230 URL: http://svn.apache.org/viewvc?rev=1211230view=rev Log: MSKINS-16: add IT and fix alt + border Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/pom.xml maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/ maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/site.xml Modified: maven/skins/trunk/maven-fluido-skin/src/main/resources/META-INF/maven/site.vm Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/pom.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/pom.xml?rev=1211230view=auto == --- maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/pom.xml (added) +++ maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/pom.xml Tue Dec 6 23:42:37 2011 @@ -0,0 +1,75 @@ +?xml version=1.0 encoding=UTF-8? +!-- + 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. +-- +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; + modelVersion4.0.0/modelVersion + + groupIdorg.apache.maven.skins.its/groupId + artifactIdmskins-16/artifactId + version1.0-SNAPSHOT/version + + properties + skinName@project.name@/skinName + skinDescription@project.description@/skinDescription + skinGroupId@project.groupId@/skinGroupId + skinArtifactId@project.artifactId@/skinArtifactId + skinVersion@project.version@/skinVersion + /properties + + build + plugins + plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-site-plugin/artifactId + version3.0/version + /plugin + /plugins + /build + + reporting + plugins + plugin + groupIdorg.apache.maven.plugins/groupId + artifactIdmaven-project-info-reports-plugin/artifactId + version2.4/version + configuration + dependencyDetailsEnabledfalse/dependencyDetailsEnabled + dependencyLocationsEnabledfalse/dependencyLocationsEnabled + /configuration + reportSets + reportSet + reports + reportindex/report + reportsummary/report + reportlicense/report + reportproject-team/report + reportscm/report + reportissue-tracking/report + reportmailing-list/report + reportdependencies/report + reportcim/report + reportplugin-management/report + reportplugins/report + /reports + /reportSet + /reportSets + /plugin + /plugins + /reporting + +/project \ No newline at end of file Added: maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/site.xml URL: http://svn.apache.org/viewvc/maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/site.xml?rev=1211230view=auto == --- maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/site.xml (added) +++ maven/skins/trunk/maven-fluido-skin/src/it/mskins-16/src/site/site.xml Tue Dec 6 23:42:37 2011 @@ -0,0 +1,51 @@ +?xml version=1.0 encoding=UTF-8? + +!-- +/* + * 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
[site] missing project name prefix in title in the generated page
Hi all guys, while redeploying the Cocoon3 site, using mvn3+site-plugin:3.0, I noticed a big difference in the generated page using mvn2+site-plugin:2.X, indeed the old tools used the project name defined in site.xml, i.e project name=Cocoon 3 ... /project to put as a prefix in generated page, i.e. html head titleCocoon 3 - ... [...] using the new tools, that doesn't happen. Did I miss something in the changelist or it is a known feature/bug? Many thanks in advance, all the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Migration plan to commons-exec
wearing both caps of commons PMC and maven Committer, I'm (not binding) +1 :) Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Nov 30, 2011 at 11:13 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Some time ago I did a very thorough review of commons-exec as a replacement for executeCommandLine in plexus-utils. commons-exec is a relative of plexus-utils executeCommandLine, as can be seen from the initial project description at https://github.com/apache/commons-exec/blob/trunk/STATUS . I was very pleased with the code (and vastly superiour test coverage!) and I would like to replace its usage in /all/ of maven in one operation. I went through all the patches we have applied to plexus-utils and I have one more minor patch that I'll get simo/olamy to apply for commons-exec, and thereafter hopefully release a minor update to commons-exec. When that is done I figured I'd do all the maven clients in one sitting. WDYT ? Kristian - 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: Migration plan to commons-exec
as we Italian says: better later than never, we now have the chance to improve both commons-exec and maven! :) All the best! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Nov 30, 2011 at 11:39 AM, Brett Porter br...@apache.org wrote: Great! Long overdue. (I see it's 6 years 4 months since I checked in the STATUS file on commons-exec, with this very intent... :) On 30/11/2011, at 9:13 PM, Kristian Rosenvold wrote: Some time ago I did a very thorough review of commons-exec as a replacement for executeCommandLine in plexus-utils. commons-exec is a relative of plexus-utils executeCommandLine, as can be seen from the initial project description at https://github.com/apache/commons-exec/blob/trunk/STATUS . I was very pleased with the code (and vastly superiour test coverage!) and I would like to replace its usage in /all/ of maven in one operation. I went through all the patches we have applied to plexus-utils and I have one more minor patch that I'll get simo/olamy to apply for commons-exec, and thereafter hopefully release a minor update to commons-exec. When that is done I figured I'd do all the maven clients in one sitting. WDYT ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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
