Re: Anakia and texen in the repository

[Henning Schmiedehausen]

Thank you for the clarification, Carlos.

Can you fix the repo to use the new id's (org.apache.texen and
org.apache.anakia) by renaming the directories back and remove the
velocity-anakia and velocity-texen groups or can we do this ourselves?

Best regards
Henning


Carlos Sanchez schrieb:
> unfortunately there's no tooling for policy enforcement in the repo
> and we are force to deal with issues like this after things are
> deployed and before they get propagated to the mirrors. It's not the
> best solution, but is the only one right now.
> And I'm trying to solve future problems based on past experiences.
> 
> The m1 and m2 repos are automatically converted to each other, so you
> only need to deploy to one of them.
> 
> Policies are the same, you can use old groupIds or use new ones under
> org.apache.*
> 
> You can put under m1 repo org.apache.velocity groupid, no problem with
> that. For convenience people usually deploy with ant or m1 to the m1
> repo and with m2 to the m2 repo.
> 
> Another different issue is the group naming convention, for me it'd
> make sense that anakia and texen were under org.apache.velocity.*
> based on my experience and considering the explosion of groups that
> could happen if all subprojects start using top level groupIds. AFAIK
> there's no policy about this, so that's just my suggestion.
> 
> What it is a policy is that all releases must be PGP signed, and also
> you have to remove the repositories/repository entry
> "http://people.apache.org/repo/m2-ibiblio-rsync-repository"; from the
> poms as it's internal use only.
> 
> Sorry for the trouble. For me it'd be also easier to forget about it,
> but in the long term this is going to save problems.
> 
> 
> On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
>> Carlos,
>>
>> please stop this.
>>
>> For maven-1, we either keep texen and anakia in the velocity group or
>> drop it completely from there. That is fine with me, no more groups,
>> yadda, yadda.
>>
>> However, for maven-2 we will adhere to your 'standards'. This means, the
>> packages go into org.apache.texen and org.apache.anakia. That is the way
>> *you* as repo people recommended it.
>>
>> If you have a problem with the jar being twice in your repo, well, maybe
>> it is time that you get your act together and have an uniform policy for
>> maven-1 and maven-2.
>>
>> If you do not agree here, then we will go to org.apache.texen and
>> org.apache.anakia and drop the jars in the velocity group. I am not
>> really interested in second guessing what you want to have and how you
>> intend to organize it. The maven repos are a distribution mechanism, not
>> a policy tool.
>>
>> Please rename the .bak directories. Feel free to drop the jars from the
>> velocity group at your discretion, I do not really care.
>>
>>
>>
>> Best regards
>> Henning
>>
>>
>>
>>
>> Carlos Sanchez schrieb:
>> > I guess these are the same as the ones in
>> > http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars
>> >
>> > - they should be only in the m1 OR m2 repo
>> > - Putting them in two different groupIds is confusing
>> > - if they are subprojects of velocity they should be in
>> > org.apache.velocity.*
>> > - missing PGP signatures
>> >
>> > I've moved anakia and texen out of the way for the moment (to .bak)
>> >
>> >
>> > On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> wrote:
>> >> Repository changed
>> >> ==
>> >>
>> >> Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/
>> >>
>> >> Added
>> >> -
>> >> [henning] org/apache/anakia
>> >> [henning] org/apache/anakia/anakia
>> >> [henning] org/apache/anakia/anakia/1.0
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5
>> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1
>> >> [henning] org/apache/anakia/anakia/maven-metadata.xml
>> >> [henning] org/apache/anakia/anakia/maven-metadata.xml.md5
>> >> [henning] org/apache/anakia/anakia/maven-metadata.xml.sha1
>> >> [henning] org/apache/texen
>> >> [henning] org/apache/texen/texen
>> >> [henning] org/apache/texen/texen/1.0
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.md5
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.sha1
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.md5
>> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.sha1
>> >> [henning] org/apache/texen/texen/maven-metadata.xml
>> >> [henning] org/apache/texen/texen/maven-metadata.xml.md5
>> >> [henning] org/apache/texen/texen/maven-metadata.xml.sha1
>> >>
>> >> Removed
>> >> ---
>> >>
>

Re: Anakia and texen in the repository

[Henning Schmiedehausen]

Hi,

no, the policy set with maven-2 and also by the repo people is to use
the package name of the application as it builds nicely into a tree and
avoids having thousands of one-level subdirectories. This has been set
in http://www.apache.org/dev/repository-faq.html (FAQ #1, they seek to
phase out m1 repos).

So for anakia this is org.apache.anakia, for texen it is
org.apache.texen. The repo is not really about project relations and
"this is part of velocity, let's have velocity somewhere". It is a
machine readable tree for downloading dependencies.

Best regards
Henning


Will Glass-Husain schrieb:
> Henning,
> 
> 
> FYI...Like you, I am not super happy about the jar files being moved
> around (though I think all parties have the best of intentions).   It'd
> make sense to me to us the name in the jar path as the group id, e.g.
> org.apache.anakia is anakia, or perhaps velocity-anakia.  I'm following
> this - but think it's best we speak with one voice so am deferring to
> you for correspondence with Carlos.
> 
> Best, WILL
> 
> On 5/1/07, *Carlos Sanchez* <[EMAIL PROTECTED]
> > wrote:
> 
> unfortunately there's no tooling for policy enforcement in the repo
> and we are force to deal with issues like this after things are
> deployed and before they get propagated to the mirrors. It's not the
> best solution, but is the only one right now.
> And I'm trying to solve future problems based on past experiences.
> 
> The m1 and m2 repos are automatically converted to each other, so you
> only need to deploy to one of them.
> 
> Policies are the same, you can use old groupIds or use new ones under
> org.apache.*
> 
> You can put under m1 repo org.apache.velocity groupid, no problem with
> that. For convenience people usually deploy with ant or m1 to the m1
> repo and with m2 to the m2 repo.
> 
> Another different issue is the group naming convention, for me it'd
> make sense that anakia and texen were under org.apache.velocity.*
> based on my experience and considering the explosion of groups that
> could happen if all subprojects start using top level groupIds. AFAIK
> there's no policy about this, so that's just my suggestion.
> 
> What it is a policy is that all releases must be PGP signed, and also
> you have to remove the repositories/repository entry
> "http://people.apache.org/repo/m2-ibiblio-rsync-repository
> " from the
> poms as it's internal use only.
> 
> Sorry for the trouble. For me it'd be also easier to forget about it,
> but in the long term this is going to save problems.
> 
> 
> On 5/1/07, Henning Schmiedehausen < [EMAIL PROTECTED]
> > wrote:
> > Carlos,
> >
> > please stop this.
> >
> > For maven-1, we either keep texen and anakia in the velocity group or
> > drop it completely from there. That is fine with me, no more groups,
> > yadda, yadda.
> >
> > However, for maven-2 we will adhere to your 'standards'. This
> means, the
> > packages go into org.apache.texen and org.apache.anakia. That is
> the way
> > *you* as repo people recommended it.
> >
> > If you have a problem with the jar being twice in your repo, well,
> maybe
> > it is time that you get your act together and have an uniform
> policy for
> > maven-1 and maven-2.
> >
> > If you do not agree here, then we will go to org.apache.texen and
> > org.apache.anakia and drop the jars in the velocity group. I am not
> > really interested in second guessing what you want to have and how you
> > intend to organize it. The maven repos are a distribution
> mechanism, not
> > a policy tool.
> >
> > Please rename the .bak directories. Feel free to drop the jars
> from the
> > velocity group at your discretion, I do not really care.
> >
> >
> >
> > Best regards
> > Henning
> >
> >
> >
> >
> > Carlos Sanchez schrieb:
> > > I guess these are the same as the ones in
> > >
> http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars
> > >
> > > - they should be only in the m1 OR m2 repo
> > > - Putting them in two different groupIds is confusing
> > > - if they are subprojects of velocity they should be in
> > > org.apache.velocity.*
> > > - missing PGP signatures
> > >
> > > I've moved anakia and texen out of the way for the moment (to .bak)
> > >
> > >
> > > On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]
> > wrote:
> > >> Repository changed
> > >> ==
> > >>
> > >> Repository:
> /www/people.apache.org/repo/m2-ibiblio-rsync-repository/
> > >>
> 

[Velocity Wiki] Trivial Update of "VelocityTools2Planning" by NathanBubna

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Velocity Wiki" for 
change notification.

The following page has been changed by NathanBubna:
http://wiki.apache.org/velocity/VelocityTools2Planning

The comment on the change is:
status update

--
  == Ideas For VelocityTools 2.x ==
  
- 1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea 
here is to have a Toolbox, which will instantiate a tool from its tool-info 
only when the generic getter is called. This should be a quite interesting 
performance gain in some situations.  If it seems useful, we could add a 
special attribute to force a tool to be instantiated at toolbox initialization 
('instantiate-on-load' ?).  The Toolboxes may then pool or at least hold on to 
instantiated tools for subsequent requests from the template or from other 
parts of the webapp (see idea 2 below).  (STATUS: done except for the 
'instantiate-on-load' attribute, but all needs testing)
+ 1. TransparentOnDemandToolsLoading: Instead of a standard HashMap, the idea 
here is to have a Toolbox, which will instantiate a tool from its tool-info 
only when the generic getter is called. This should be a quite interesting 
performance gain in some situations.  If it seems useful, we could add a 
special attribute to force a tool to be instantiated at toolbox initialization 
('instantiate-on-load' ?).  The Toolboxes may then pool or at least hold on to 
instantiated tools for subsequent requests from the template or from other 
parts of the webapp (see idea 2 below).  (STATUS: done except for the 
'instantiate-on-load' attribute)
  
  2. EasierToolAccessOutsideTemplates: Other objects in my webapp are often 
jealous of the VelocityViewServlet. They also would like to use some of the 
tools. Session scoped tools can be reached via the session, but it's not the 
case for application or request scoped tools. To achieve this, there would be a 
few things to do:
   * create a separate Toolbox for each scope and store it in the attributes of 
the corresponding servlet API object (request->!ServletRequest, 
session->!HttpSession, application->!ServletContext). (STATUS: done)
@@ -24, +24 @@

  
  
  
- 
+ 
  
  
  }}}
- (STATUS: done, but needs testing)
+ (STATUS: done, and now our tools come with a @!DefaultKey annotation to make 
it even simpler)
  
- 4. FactorOutBasicVelocityViewStuff:  This would create a better basis for 
bring the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the 
project as a sibling of the VelocityViewServlet. (STATUS: mostly done)
+ 4. FactorOutBasicVelocityViewStuff:  This would create a better basis for 
bring the [http://velocity.apache.org/engine/devel/veltag.html Veltag] into the 
project as a sibling of the VelocityViewServlet. (STATUS: pretty much done)
  
  5. SupportAlternateToolboxConfiguration: Not everyone likes XML.  I'd like us 
to make Toolbox management pluggable with provided support for configuration 
via properties file as well as XML, and i want it to be easier to configure and 
manage in Java as well. (STATUS: done, but needs testing)
  
@@ -39, +39 @@

  == Backwards Compatibility For VelocityTools 2.x ==
  
  1. Basic user interfaces - these are things that people use directly without 
extending
-   * Our tools - the biggest thing here is the tools themselves.  we shouldn't 
make users have to change their templates at all.  we might consider finding 
some way to provide deprecation notices for things we'd like to change, but i 
don't think there's many places we'll need to do that.  in the meantime, the 
most we may do is move packages, add setup() methods, and put deprecated 
subclasses with init() and configure() support in the old tool locations. 
(STATUS: nothing to be done yet)
+   * Our tools - the biggest thing here is the tools themselves.  we shouldn't 
make users have to change their templates at all.  we might consider finding 
some way to provide deprecation notices for things we'd like to change, but i 
don't think there's many places we'll need to do that.  in the meantime, the 
most we may do is move packages, add setup() methods, and put deprecated 
subclasses with init() and configure() support in the old tool locations. 
(STATUS: only a little bit done)
* Custom tools - the trick will be to support the init() and configure() 
methods.  Not sure how this will work, but i'm pretty determined to find a way. 
(STATUS: not done yet)
* Servlets - A lot of people directly use the VVS and VLS.  So, while i've 
moved them to a new package, there are  deprecated subclasses at their old 
location to make this a seamless transition for these folks. (STATUS: done)
-   * toolbox.xml - We need to create a !FactoryConfiguration that can 
translate the old xml configuration format to fit the new tool management 
structure.  This should not be too difficult.  

Re: Anakia and texen in the repository

[Will Glass-Husain]

Henning,


FYI...Like you, I am not super happy about the jar files being moved around
(though I think all parties have the best of intentions).   It'd make sense
to me to us the name in the jar path as the group id, e.g.
org.apache.anakiais anakia, or perhaps velocity-anakia.  I'm following
this - but think it's
best we speak with one voice so am deferring to you for correspondence with
Carlos.

Best, WILL

On 5/1/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


unfortunately there's no tooling for policy enforcement in the repo
and we are force to deal with issues like this after things are
deployed and before they get propagated to the mirrors. It's not the
best solution, but is the only one right now.
And I'm trying to solve future problems based on past experiences.

The m1 and m2 repos are automatically converted to each other, so you
only need to deploy to one of them.

Policies are the same, you can use old groupIds or use new ones under
org.apache.*

You can put under m1 repo org.apache.velocity groupid, no problem with
that. For convenience people usually deploy with ant or m1 to the m1
repo and with m2 to the m2 repo.

Another different issue is the group naming convention, for me it'd
make sense that anakia and texen were under org.apache.velocity.*
based on my experience and considering the explosion of groups that
could happen if all subprojects start using top level groupIds. AFAIK
there's no policy about this, so that's just my suggestion.

What it is a policy is that all releases must be PGP signed, and also
you have to remove the repositories/repository entry
"http://people.apache.org/repo/m2-ibiblio-rsync-repository"; from the
poms as it's internal use only.

Sorry for the trouble. For me it'd be also easier to forget about it,
but in the long term this is going to save problems.


On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:
> Carlos,
>
> please stop this.
>
> For maven-1, we either keep texen and anakia in the velocity group or
> drop it completely from there. That is fine with me, no more groups,
> yadda, yadda.
>
> However, for maven-2 we will adhere to your 'standards'. This means, the
> packages go into org.apache.texen and org.apache.anakia. That is the way
> *you* as repo people recommended it.
>
> If you have a problem with the jar being twice in your repo, well, maybe
> it is time that you get your act together and have an uniform policy for
> maven-1 and maven-2.
>
> If you do not agree here, then we will go to org.apache.texen and
> org.apache.anakia and drop the jars in the velocity group. I am not
> really interested in second guessing what you want to have and how you
> intend to organize it. The maven repos are a distribution mechanism, not
> a policy tool.
>
> Please rename the .bak directories. Feel free to drop the jars from the
> velocity group at your discretion, I do not really care.
>
>
>
> Best regards
> Henning
>
>
>
>
> Carlos Sanchez schrieb:
> > I guess these are the same as the ones in
> >
http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars
> >
> > - they should be only in the m1 OR m2 repo
> > - Putting them in two different groupIds is confusing
> > - if they are subprojects of velocity they should be in
> > org.apache.velocity.*
> > - missing PGP signatures
> >
> > I've moved anakia and texen out of the way for the moment (to .bak)
> >
> >
> > On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> >> Repository changed
> >> ==
> >>
> >> Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/
> >>
> >> Added
> >> -
> >> [henning] org/apache/anakia
> >> [henning] org/apache/anakia/anakia
> >> [henning] org/apache/anakia/anakia/1.0
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5
> >> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1
> >> [henning] org/apache/anakia/anakia/maven-metadata.xml
> >> [henning] org/apache/anakia/anakia/maven-metadata.xml.md5
> >> [henning] org/apache/anakia/anakia/maven-metadata.xml.sha1
> >> [henning] org/apache/texen
> >> [henning] org/apache/texen/texen
> >> [henning] org/apache/texen/texen/1.0
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.md5
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.sha1
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.md5
> >> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.sha1
> >> [henning] org/apache/texen/texen/maven-metadata.xml
> >> [henning] org/apache/texen/texen/maven-metadata.xml.md5
> >> [henning] org/apache/texen/texen/maven-metadata.xml.sha1
> >>
> >> Removed
> >> ---
> 

Re: Anakia and texen in the repository

[Carlos Sanchez]

unfortunately there's no tooling for policy enforcement in the repo
and we are force to deal with issues like this after things are
deployed and before they get propagated to the mirrors. It's not the
best solution, but is the only one right now.
And I'm trying to solve future problems based on past experiences.

The m1 and m2 repos are automatically converted to each other, so you
only need to deploy to one of them.

Policies are the same, you can use old groupIds or use new ones under
org.apache.*

You can put under m1 repo org.apache.velocity groupid, no problem with
that. For convenience people usually deploy with ant or m1 to the m1
repo and with m2 to the m2 repo.

Another different issue is the group naming convention, for me it'd
make sense that anakia and texen were under org.apache.velocity.*
based on my experience and considering the explosion of groups that
could happen if all subprojects start using top level groupIds. AFAIK
there's no policy about this, so that's just my suggestion.

What it is a policy is that all releases must be PGP signed, and also
you have to remove the repositories/repository entry
"http://people.apache.org/repo/m2-ibiblio-rsync-repository"; from the
poms as it's internal use only.

Sorry for the trouble. For me it'd be also easier to forget about it,
but in the long term this is going to save problems.


On 5/1/07, Henning Schmiedehausen <[EMAIL PROTECTED]> wrote:

Carlos,

please stop this.

For maven-1, we either keep texen and anakia in the velocity group or
drop it completely from there. That is fine with me, no more groups,
yadda, yadda.

However, for maven-2 we will adhere to your 'standards'. This means, the
packages go into org.apache.texen and org.apache.anakia. That is the way
*you* as repo people recommended it.

If you have a problem with the jar being twice in your repo, well, maybe
it is time that you get your act together and have an uniform policy for
maven-1 and maven-2.

If you do not agree here, then we will go to org.apache.texen and
org.apache.anakia and drop the jars in the velocity group. I am not
really interested in second guessing what you want to have and how you
intend to organize it. The maven repos are a distribution mechanism, not
a policy tool.

Please rename the .bak directories. Feel free to drop the jars from the
velocity group at your discretion, I do not really care.



Best regards
Henning




Carlos Sanchez schrieb:
> I guess these are the same as the ones in
> http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars
>
> - they should be only in the m1 OR m2 repo
> - Putting them in two different groupIds is confusing
> - if they are subprojects of velocity they should be in
> org.apache.velocity.*
> - missing PGP signatures
>
> I've moved anakia and texen out of the way for the moment (to .bak)
>
>
> On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Repository changed
>> ==
>>
>> Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/
>>
>> Added
>> -
>> [henning] org/apache/anakia
>> [henning] org/apache/anakia/anakia
>> [henning] org/apache/anakia/anakia/1.0
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5
>> [henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1
>> [henning] org/apache/anakia/anakia/maven-metadata.xml
>> [henning] org/apache/anakia/anakia/maven-metadata.xml.md5
>> [henning] org/apache/anakia/anakia/maven-metadata.xml.sha1
>> [henning] org/apache/texen
>> [henning] org/apache/texen/texen
>> [henning] org/apache/texen/texen/1.0
>> [henning] org/apache/texen/texen/1.0/texen-1.0.jar
>> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.md5
>> [henning] org/apache/texen/texen/1.0/texen-1.0.jar.sha1
>> [henning] org/apache/texen/texen/1.0/texen-1.0.pom
>> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.md5
>> [henning] org/apache/texen/texen/1.0/texen-1.0.pom.sha1
>> [henning] org/apache/texen/texen/maven-metadata.xml
>> [henning] org/apache/texen/texen/maven-metadata.xml.md5
>> [henning] org/apache/texen/texen/maven-metadata.xml.sha1
>>
>> Removed
>> ---
>>
>
>




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: question on site building/release process

[Henning Schmiedehausen]

BTW: I fixed the licensing report issue (which is related to offline
building). Should be fine now.

Best regards
Henning


Will Glass-Husain schrieb:
> Ok, thanks.  Guess I just have to get more familiar with this.  I
> reviewed the pom file multiple times, somehow missed those lines.  We're
> getting more consistent over time; as this process continues it'll get
> easier to follow other examples.
> 
> WILL
> 
> On 4/30/07, *Henning P. Schmiedehausen* <[EMAIL PROTECTED]
> > wrote:
> 
> "Will Glass-Husain" <[EMAIL PROTECTED]
> > writes:
> 
> >--=_Part_78854_30603569.1177873852796
> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >Content-Transfer-Encoding: 7bit
> >Content-Disposition: inline
> 
> >Thanks, Henning.  I'll review this.  This has gotten insanely
> complicated.
> >I read the (outdated) wiki docs, looked at the tools and engine
> release and
> >still got some stuff wrong.  When in double I followed the Tools
> format for
> >URL's and the like but apparently that's not all correct either.  I
> thought
> >Maven was supposed to simplify things?
> 
> Actually, it is not that complicated. It is just necessary to make
> sure that
> the changes beween a release and the devel branch are reflected in
> the code
> base. These are just a few lines in the POM.
> 
> Maven does simplify here because it allows us to build in an uniform
> manner
> over all projects. Using VelocityTools was probably just the wrong
> choice, because Nathan does not use maven to build the site (yet?
> Nathan?).
> 
> >It's a hassle that the POM's were wrong in the released file.  
> What's the
> >practical import of this?
> 
> Close to none. The repos have a patched version, so the only impact is
> some user downloading the source and rebuilding the sites locally. To
> me it is more important that the links on the web site are ok.
> 
> Best regards
> Henning
> 
> 
> 
> >On 4/29/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]
> > wrote:
> >>
> >> "Will Glass-Husain" < [EMAIL PROTECTED]
> > writes:
> >>
> >> >(1) How do I get the site to build for
> >> > http://velocity.apache.org/engine/releases/anakia-1.0/
> >>
> >> This is what I would have done: (shown for anakia, same for texen)
> >>
> >> - create a release branch: branches/anakia-1.0 (has been done)
> >> (BTW: Can we get an uniform capitalization policy here? All ups, all
> >>   downs, use '-' or '_' etc)
> >>
> >> - update the pom.xml file:
> >>
> >>   jar
> >>
> >>   http://velocity.apache.org/anakia/releases/anakia-1.0
> >>   
> >> scm:svn:
> >> http://svn.apache.org/repos/asf/velocity/anakia/tags/anakia-1.0
> >> 
> >> scm:svn:
> >> https://svn.apache.org/repos/asf/velocity/anakia/tags/anakia-1.0
> >> 
> >>  anakia-1.0
> >> 
> http://svn.apache.org/viewvc/velocity/anakia/tags/anakia-1.0
> >> 
> >>   
> >>
> >>   
> >> 
> >>...
> >>
> >>
> 
> scpexe://people.apache.org/www/velocity.apache.org/anakia/releases/anakia-
> >> 1.0
> >>   ...
> >>
> >>   Also update the  field for the maven-changes-plugin
> >>
> >>   The patched POMs for texen and anakia are on
> >>
> >>
> velocity.zones:~velocity/deploy/releases/velocity-anakia-1.0-site/pom.xml
> >>   and ~velocity/deploy/releases/velocity-texen-1.0-site/pom.xml.
> These are
> >>   the poms that also went up to the maven-2 repo. We probably
> want to
> >>   streamline this process further.
> >>
> >> - roll the tarball from that branch
> >>
> >> - vote on that tarball (else the files inside the tarball would
> contain
> >> the wrong URLs)
> >>
> >> - if voted, copy the branch to the tag
> >>
> >> - release the tarball.
> >>
> >> We botched that part, the released jars contain a wrong pom with the
> >> devel links. As I am probably the only one that would have looked at
> >> this, I am guilty of neglecting oversight here. :-/ We could discuss
> >> whether this is a brown-paperbag bug and fire an anakia/texen 1.0.1
> >> bug fix release with fixed POMs.
> >>
> >> - Update the site through velocity.zones.apache.org
>  by building a
> >> short script similar to the development site scripts (see
> >> http://wiki.apache.org/velocity/RebuildSites).
> >>
> >> I have added scripts to the ~velocity/bin directory and deployed the
> >> sites.
> >>
> >> Please *DO NOT* just copy the devel sites over:
> >>
> >>   - The navigation links will be wrong (the releases

[Velocity Wiki] Update of "VelocityDocbook" by HenningSchmiedehausen

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Velocity Wiki" for 
change notification.

The following page has been changed by HenningSchmiedehausen:
http://wiki.apache.org/velocity/VelocityDocbook

The comment on the change is:
update references.

--
  
  If you came here, there is a chance that you stumbled over some docs on the 
web site or attended the "Apache Project Documentation" lightning talk at AC US 
2006.
  
- The Velocity Docbook Framework is intended to render all docs for Velocity 
1.5 and beyond using the [http://www.docbook.org DocBook] format. The framework 
itself is still under development, you can check it out from our Subversion 
repository at [http://svn.apache.org/repos/asf/jakarta/velocity/docbook/trunk/].
+ The Velocity Docbook Framework is intended to render all docs for Velocity 
1.5 and beyond using the [http://www.docbook.org DocBook] format. 
+ It has been released as [http://velocity.apache.org/docbook/ DocBook 
Framework]. 
  
- There is documentation on how to use this framework in the 
[http://svn.apache.org/repos/asf/jakarta/velocity/docbook/trunk/README README] 
file. Be sure to read the 
[http://svn.apache.org/repos/asf/jakarta/velocity/docbook/trunk/README.FIRST 
README.FIRST] file. Some Velocity specific information is in 
[http://svn.apache.org/repos/asf/jakarta/velocity/docbook/trunk/README.velocity 
README.velocity].
+ There is documentation on how to use this framework in the 
[http://velocity.apache.org/docbook/DocBook-Framework-1.0.pdf Documentation]. 
Some Velocity specific information is in 
[http://svn.apache.org/repos/asf/velocity/docs/README.velocity README.velocity].
  

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

Re: Anakia and texen in the repository

[Henning Schmiedehausen]

Carlos,

please stop this.

For maven-1, we either keep texen and anakia in the velocity group or 
drop it completely from there. That is fine with me, no more groups, 
yadda, yadda.


However, for maven-2 we will adhere to your 'standards'. This means, the 
packages go into org.apache.texen and org.apache.anakia. That is the way 
*you* as repo people recommended it.


If you have a problem with the jar being twice in your repo, well, maybe 
it is time that you get your act together and have an uniform policy for 
maven-1 and maven-2.


If you do not agree here, then we will go to org.apache.texen and 
org.apache.anakia and drop the jars in the velocity group. I am not 
really interested in second guessing what you want to have and how you 
intend to organize it. The maven repos are a distribution mechanism, not 
a policy tool.


Please rename the .bak directories. Feel free to drop the jars from the 
velocity group at your discretion, I do not really care.




Best regards
Henning




Carlos Sanchez schrieb:

I guess these are the same as the ones in
http://people.apache.org/repo/m1-ibiblio-rsync-repository/velocity/jars

- they should be only in the m1 OR m2 repo
- Putting them in two different groupIds is confusing
- if they are subprojects of velocity they should be in 
org.apache.velocity.*

- missing PGP signatures

I've moved anakia and texen out of the way for the moment (to .bak)


On 30 Apr 2007 08:16:24 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Repository changed
==

Repository: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/

Added
-
[henning] org/apache/anakia
[henning] org/apache/anakia/anakia
[henning] org/apache/anakia/anakia/1.0
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.md5
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.jar.sha1
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.md5
[henning] org/apache/anakia/anakia/1.0/anakia-1.0.pom.sha1
[henning] org/apache/anakia/anakia/maven-metadata.xml
[henning] org/apache/anakia/anakia/maven-metadata.xml.md5
[henning] org/apache/anakia/anakia/maven-metadata.xml.sha1
[henning] org/apache/texen
[henning] org/apache/texen/texen
[henning] org/apache/texen/texen/1.0
[henning] org/apache/texen/texen/1.0/texen-1.0.jar
[henning] org/apache/texen/texen/1.0/texen-1.0.jar.md5
[henning] org/apache/texen/texen/1.0/texen-1.0.jar.sha1
[henning] org/apache/texen/texen/1.0/texen-1.0.pom
[henning] org/apache/texen/texen/1.0/texen-1.0.pom.md5
[henning] org/apache/texen/texen/1.0/texen-1.0.pom.sha1
[henning] org/apache/texen/texen/maven-metadata.xml
[henning] org/apache/texen/texen/maven-metadata.xml.md5
[henning] org/apache/texen/texen/maven-metadata.xml.sha1

Removed
---






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