You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Kalle Korhonen <ka...@gmail.com> on 2009/08/23 05:53:13 UTC
Trunk clean-up?
There are a few small errors in the trunk and some and some
folders/files that would need to be ignore from svn. I could easily
write up a patch to clean it up (I like my source tree all clean and
nice so nothing would mask the real errors), but would the committers
accept it, and if so, should I open an issue for each of them
separately or one for all? It'd cut down on bureaucracy if somebody
with commit rights would do them directly. Here's a few for reference:
- package-info.java in shiro-core/src/main/java/org/apache/shiro needs
to declare org.apache.shiro (not org.shiro).
- all target folders need to be added to svn:ignore
- IDE specific files should be added to svn:ignore
- why is javadoc generated as part of regular install goal?
Kalle
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
I created the patch with Tortoise since it was dealing with multiple
modules - do install it, the interface is very nice. Command-line,
IDE-specific and TortoiseSVN should all work together - I use them all
depending on the task at hand.
Kalle
On Mon, Aug 24, 2009 at 11:15 AM, Les Hazlewood<lh...@apache.org> wrote:
> I tried to apply this patch, but it didn't work in IntelliJ and I have
> no idea why. I suspect I might need to use a command line client to
> do this one, but I'm on Windows at the moment, and the command line is
> --- well... you know ;) (and I don't have Tortoise installed - I might
> just have to wait to do this on my Mac later tonight).
>
> On Mon, Aug 24, 2009 at 1:07 PM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> Thanks for a quick turnaround. I had already opened an issue against
>> adding items to svn:ignore, just prepared a new patch against the
>> latest trunk (with SHIRO-87 included!) and attached to the same issue
>> that was still open. https://issues.apache.org/jira/browse/SHIRO-43 if
>> you are in the mood for applying more patches - should be trivial and
>> safe to do.
>>
>> Kalle
>>
>>
>> On Mon, Aug 24, 2009 at 9:52 AM, Les Hazlewood<lh...@apache.org> wrote:
>>> Sounds good - I applied it :)
>>>
>>> I typically use the 'fix version' to be the next unreleased version.
>>> The 'Incubator' version is more like a backlog of everything that
>>> needs to be complete before we can graduate.
>>>
>>> Thanks for the help!
>>>
>>> Les
>>>
>>> On Mon, Aug 24, 2009 at 12:44 PM, Kalle
>>> Korhonen<ka...@gmail.com> wrote:
>>>> Coming in one by one - this is trivial:
>>>> https://issues.apache.org/jira/browse/SHIRO-87. Let me know if I
>>>> should be using different affect/fix versions. Normally I attach a
>>>> patch file, but since it was so trivial, would be just as easy to fix
>>>> by hand.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>>> Great, thanks very much for this Kalle.
>>>>>
>>>>> +1 to removing the JavaDoc as part of the install process to shorten
>>>>> build times. I wouldn't want to move it to a profile until we can
>>>>> also guarantee it executes during the deploy goal so the build server
>>>>> produces them during the normal deployment. I'm sure this is an easy
>>>>> fix that I'm overlooking...
>>>>>
>>>>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>>>>> Korhonen<ka...@gmail.com> wrote:
>>>>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>>>>> I'd be happy to add any patches you might be able to contribute. I
>>>>>>> agree that there is still some cleanup left like what you recommend.
>>>>>>> I think it might make more sense to include these as patches to
>>>>>>> different Jira issues just in case one or more of them need to be
>>>>>>> discussed first.
>>>>>>
>>>>>> Ok, I'll open 2-3 issues with small patches.
>>>>>>
>>>>>>> As for the javadoc, I just added that back really quickly before our
>>>>>>> first maven deployment to ensure that it would be uploaded. For some
>>>>>>> reason the previous configuration didn't seem to be generating it at
>>>>>>> all. Where should it go? I personally don't really care how it is
>>>>>>> defined as long as it is generated and uploaded each time a deployment
>>>>>>> is done. Any patches/recommendations for that?
>>>>>>
>>>>>> By default javadoc:jar binds to package phase, which is the
>>>>>> recommended usage. However, it takes some time and the most common
>>>>>> Maven command is mvn install so it makes sense to try to optimize the
>>>>>> execution time of it. For one project at work the javadoc is created
>>>>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>>>>> install. However, the most common way to do it is to generate javadoc
>>>>>> as part of site deployment (I think site plugin executes it even by
>>>>>> default). We could do it with a profile for now while we think about
>>>>>> the site deployment some more (as part of the other email thread).
>>>>>> I'll create an issue and add a patch.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>>>>> Korhonen<ka...@gmail.com> wrote:
>>>>>>>> There are a few small errors in the trunk and some and some
>>>>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>>>>> nice so nothing would mask the real errors), but would the committers
>>>>>>>> accept it, and if so, should I open an issue for each of them
>>>>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>>>>
>>>>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>>>>> to declare org.apache.shiro (not org.shiro).
>>>>>>>> - all target folders need to be added to svn:ignore
>>>>>>>> - IDE specific files should be added to svn:ignore
>>>>>>>> - why is javadoc generated as part of regular install goal?
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Les Hazlewood <lh...@apache.org>.
I tried to apply this patch, but it didn't work in IntelliJ and I have
no idea why. I suspect I might need to use a command line client to
do this one, but I'm on Windows at the moment, and the command line is
--- well... you know ;) (and I don't have Tortoise installed - I might
just have to wait to do this on my Mac later tonight).
On Mon, Aug 24, 2009 at 1:07 PM, Kalle
Korhonen<ka...@gmail.com> wrote:
> Thanks for a quick turnaround. I had already opened an issue against
> adding items to svn:ignore, just prepared a new patch against the
> latest trunk (with SHIRO-87 included!) and attached to the same issue
> that was still open. https://issues.apache.org/jira/browse/SHIRO-43 if
> you are in the mood for applying more patches - should be trivial and
> safe to do.
>
> Kalle
>
>
> On Mon, Aug 24, 2009 at 9:52 AM, Les Hazlewood<lh...@apache.org> wrote:
>> Sounds good - I applied it :)
>>
>> I typically use the 'fix version' to be the next unreleased version.
>> The 'Incubator' version is more like a backlog of everything that
>> needs to be complete before we can graduate.
>>
>> Thanks for the help!
>>
>> Les
>>
>> On Mon, Aug 24, 2009 at 12:44 PM, Kalle
>> Korhonen<ka...@gmail.com> wrote:
>>> Coming in one by one - this is trivial:
>>> https://issues.apache.org/jira/browse/SHIRO-87. Let me know if I
>>> should be using different affect/fix versions. Normally I attach a
>>> patch file, but since it was so trivial, would be just as easy to fix
>>> by hand.
>>>
>>> Kalle
>>>
>>>
>>> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>> Great, thanks very much for this Kalle.
>>>>
>>>> +1 to removing the JavaDoc as part of the install process to shorten
>>>> build times. I wouldn't want to move it to a profile until we can
>>>> also guarantee it executes during the deploy goal so the build server
>>>> produces them during the normal deployment. I'm sure this is an easy
>>>> fix that I'm overlooking...
>>>>
>>>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>>>> Korhonen<ka...@gmail.com> wrote:
>>>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>>>> I'd be happy to add any patches you might be able to contribute. I
>>>>>> agree that there is still some cleanup left like what you recommend.
>>>>>> I think it might make more sense to include these as patches to
>>>>>> different Jira issues just in case one or more of them need to be
>>>>>> discussed first.
>>>>>
>>>>> Ok, I'll open 2-3 issues with small patches.
>>>>>
>>>>>> As for the javadoc, I just added that back really quickly before our
>>>>>> first maven deployment to ensure that it would be uploaded. For some
>>>>>> reason the previous configuration didn't seem to be generating it at
>>>>>> all. Where should it go? I personally don't really care how it is
>>>>>> defined as long as it is generated and uploaded each time a deployment
>>>>>> is done. Any patches/recommendations for that?
>>>>>
>>>>> By default javadoc:jar binds to package phase, which is the
>>>>> recommended usage. However, it takes some time and the most common
>>>>> Maven command is mvn install so it makes sense to try to optimize the
>>>>> execution time of it. For one project at work the javadoc is created
>>>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>>>> install. However, the most common way to do it is to generate javadoc
>>>>> as part of site deployment (I think site plugin executes it even by
>>>>> default). We could do it with a profile for now while we think about
>>>>> the site deployment some more (as part of the other email thread).
>>>>> I'll create an issue and add a patch.
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>>>> Korhonen<ka...@gmail.com> wrote:
>>>>>>> There are a few small errors in the trunk and some and some
>>>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>>>> nice so nothing would mask the real errors), but would the committers
>>>>>>> accept it, and if so, should I open an issue for each of them
>>>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>>>
>>>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>>>> to declare org.apache.shiro (not org.shiro).
>>>>>>> - all target folders need to be added to svn:ignore
>>>>>>> - IDE specific files should be added to svn:ignore
>>>>>>> - why is javadoc generated as part of regular install goal?
>>>>>>>
>>>>>>> Kalle
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
Thanks for a quick turnaround. I had already opened an issue against
adding items to svn:ignore, just prepared a new patch against the
latest trunk (with SHIRO-87 included!) and attached to the same issue
that was still open. https://issues.apache.org/jira/browse/SHIRO-43 if
you are in the mood for applying more patches - should be trivial and
safe to do.
Kalle
On Mon, Aug 24, 2009 at 9:52 AM, Les Hazlewood<lh...@apache.org> wrote:
> Sounds good - I applied it :)
>
> I typically use the 'fix version' to be the next unreleased version.
> The 'Incubator' version is more like a backlog of everything that
> needs to be complete before we can graduate.
>
> Thanks for the help!
>
> Les
>
> On Mon, Aug 24, 2009 at 12:44 PM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> Coming in one by one - this is trivial:
>> https://issues.apache.org/jira/browse/SHIRO-87. Let me know if I
>> should be using different affect/fix versions. Normally I attach a
>> patch file, but since it was so trivial, would be just as easy to fix
>> by hand.
>>
>> Kalle
>>
>>
>> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>>> Great, thanks very much for this Kalle.
>>>
>>> +1 to removing the JavaDoc as part of the install process to shorten
>>> build times. I wouldn't want to move it to a profile until we can
>>> also guarantee it executes during the deploy goal so the build server
>>> produces them during the normal deployment. I'm sure this is an easy
>>> fix that I'm overlooking...
>>>
>>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>>> Korhonen<ka...@gmail.com> wrote:
>>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>>> I'd be happy to add any patches you might be able to contribute. I
>>>>> agree that there is still some cleanup left like what you recommend.
>>>>> I think it might make more sense to include these as patches to
>>>>> different Jira issues just in case one or more of them need to be
>>>>> discussed first.
>>>>
>>>> Ok, I'll open 2-3 issues with small patches.
>>>>
>>>>> As for the javadoc, I just added that back really quickly before our
>>>>> first maven deployment to ensure that it would be uploaded. For some
>>>>> reason the previous configuration didn't seem to be generating it at
>>>>> all. Where should it go? I personally don't really care how it is
>>>>> defined as long as it is generated and uploaded each time a deployment
>>>>> is done. Any patches/recommendations for that?
>>>>
>>>> By default javadoc:jar binds to package phase, which is the
>>>> recommended usage. However, it takes some time and the most common
>>>> Maven command is mvn install so it makes sense to try to optimize the
>>>> execution time of it. For one project at work the javadoc is created
>>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>>> install. However, the most common way to do it is to generate javadoc
>>>> as part of site deployment (I think site plugin executes it even by
>>>> default). We could do it with a profile for now while we think about
>>>> the site deployment some more (as part of the other email thread).
>>>> I'll create an issue and add a patch.
>>>>
>>>> Kalle
>>>>
>>>>
>>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>>> Korhonen<ka...@gmail.com> wrote:
>>>>>> There are a few small errors in the trunk and some and some
>>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>>> nice so nothing would mask the real errors), but would the committers
>>>>>> accept it, and if so, should I open an issue for each of them
>>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>>
>>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>>> to declare org.apache.shiro (not org.shiro).
>>>>>> - all target folders need to be added to svn:ignore
>>>>>> - IDE specific files should be added to svn:ignore
>>>>>> - why is javadoc generated as part of regular install goal?
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Les Hazlewood <lh...@apache.org>.
Sounds good - I applied it :)
I typically use the 'fix version' to be the next unreleased version.
The 'Incubator' version is more like a backlog of everything that
needs to be complete before we can graduate.
Thanks for the help!
Les
On Mon, Aug 24, 2009 at 12:44 PM, Kalle
Korhonen<ka...@gmail.com> wrote:
> Coming in one by one - this is trivial:
> https://issues.apache.org/jira/browse/SHIRO-87. Let me know if I
> should be using different affect/fix versions. Normally I attach a
> patch file, but since it was so trivial, would be just as easy to fix
> by hand.
>
> Kalle
>
>
> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>> Great, thanks very much for this Kalle.
>>
>> +1 to removing the JavaDoc as part of the install process to shorten
>> build times. I wouldn't want to move it to a profile until we can
>> also guarantee it executes during the deploy goal so the build server
>> produces them during the normal deployment. I'm sure this is an easy
>> fix that I'm overlooking...
>>
>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>> Korhonen<ka...@gmail.com> wrote:
>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>> I'd be happy to add any patches you might be able to contribute. I
>>>> agree that there is still some cleanup left like what you recommend.
>>>> I think it might make more sense to include these as patches to
>>>> different Jira issues just in case one or more of them need to be
>>>> discussed first.
>>>
>>> Ok, I'll open 2-3 issues with small patches.
>>>
>>>> As for the javadoc, I just added that back really quickly before our
>>>> first maven deployment to ensure that it would be uploaded. For some
>>>> reason the previous configuration didn't seem to be generating it at
>>>> all. Where should it go? I personally don't really care how it is
>>>> defined as long as it is generated and uploaded each time a deployment
>>>> is done. Any patches/recommendations for that?
>>>
>>> By default javadoc:jar binds to package phase, which is the
>>> recommended usage. However, it takes some time and the most common
>>> Maven command is mvn install so it makes sense to try to optimize the
>>> execution time of it. For one project at work the javadoc is created
>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>> install. However, the most common way to do it is to generate javadoc
>>> as part of site deployment (I think site plugin executes it even by
>>> default). We could do it with a profile for now while we think about
>>> the site deployment some more (as part of the other email thread).
>>> I'll create an issue and add a patch.
>>>
>>> Kalle
>>>
>>>
>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>> Korhonen<ka...@gmail.com> wrote:
>>>>> There are a few small errors in the trunk and some and some
>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>> nice so nothing would mask the real errors), but would the committers
>>>>> accept it, and if so, should I open an issue for each of them
>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>
>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>> to declare org.apache.shiro (not org.shiro).
>>>>> - all target folders need to be added to svn:ignore
>>>>> - IDE specific files should be added to svn:ignore
>>>>> - why is javadoc generated as part of regular install goal?
>>>>>
>>>>> Kalle
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
Coming in one by one - this is trivial:
https://issues.apache.org/jira/browse/SHIRO-87. Let me know if I
should be using different affect/fix versions. Normally I attach a
patch file, but since it was so trivial, would be just as easy to fix
by hand.
Kalle
On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
> Great, thanks very much for this Kalle.
>
> +1 to removing the JavaDoc as part of the install process to shorten
> build times. I wouldn't want to move it to a profile until we can
> also guarantee it executes during the deploy goal so the build server
> produces them during the normal deployment. I'm sure this is an easy
> fix that I'm overlooking...
>
> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>> I'd be happy to add any patches you might be able to contribute. I
>>> agree that there is still some cleanup left like what you recommend.
>>> I think it might make more sense to include these as patches to
>>> different Jira issues just in case one or more of them need to be
>>> discussed first.
>>
>> Ok, I'll open 2-3 issues with small patches.
>>
>>> As for the javadoc, I just added that back really quickly before our
>>> first maven deployment to ensure that it would be uploaded. For some
>>> reason the previous configuration didn't seem to be generating it at
>>> all. Where should it go? I personally don't really care how it is
>>> defined as long as it is generated and uploaded each time a deployment
>>> is done. Any patches/recommendations for that?
>>
>> By default javadoc:jar binds to package phase, which is the
>> recommended usage. However, it takes some time and the most common
>> Maven command is mvn install so it makes sense to try to optimize the
>> execution time of it. For one project at work the javadoc is created
>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>> install. However, the most common way to do it is to generate javadoc
>> as part of site deployment (I think site plugin executes it even by
>> default). We could do it with a profile for now while we think about
>> the site deployment some more (as part of the other email thread).
>> I'll create an issue and add a patch.
>>
>> Kalle
>>
>>
>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>> Korhonen<ka...@gmail.com> wrote:
>>>> There are a few small errors in the trunk and some and some
>>>> folders/files that would need to be ignore from svn. I could easily
>>>> write up a patch to clean it up (I like my source tree all clean and
>>>> nice so nothing would mask the real errors), but would the committers
>>>> accept it, and if so, should I open an issue for each of them
>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>> with commit rights would do them directly. Here's a few for reference:
>>>>
>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>> to declare org.apache.shiro (not org.shiro).
>>>> - all target folders need to be added to svn:ignore
>>>> - IDE specific files should be added to svn:ignore
>>>> - why is javadoc generated as part of regular install goal?
>>>>
>>>> Kalle
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Les Hazlewood <lh...@apache.org>.
Hi Kalle,
Thanks again - I'm grateful for anything you're willing to contribute!
Please feel free to do the same for any tests or anything else you
feel might be improved.
- Les
On Mon, Aug 24, 2009 at 10:14 PM, Kalle
Korhonen<ka...@gmail.com> wrote:
> Issue and patch for the javadoc profile:
> https://issues.apache.org/jira/browse/SHIRO-88
>
> Kalle
>
> PS. I also see some unstable/unreliable tests, maybe I can harden them a bit...
>
>
> On Mon, Aug 24, 2009 at 4:16 PM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> The usual way is deploy the site and publish javadocs as part of the
>> site. If not that, then the alternative is invoking it via a profile.
>> mvn -P javadoc deploy would work just the same (the current javadoc
>> plugin configuration would just move to the profile, no other changes
>> needed).
>>
>> Kalle
>>
>> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>>> Great, thanks very much for this Kalle.
>>>
>>> +1 to removing the JavaDoc as part of the install process to shorten
>>> build times. I wouldn't want to move it to a profile until we can
>>> also guarantee it executes during the deploy goal so the build server
>>> produces them during the normal deployment. I'm sure this is an easy
>>> fix that I'm overlooking...
>>>
>>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>>> Korhonen<ka...@gmail.com> wrote:
>>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>>> I'd be happy to add any patches you might be able to contribute. I
>>>>> agree that there is still some cleanup left like what you recommend.
>>>>> I think it might make more sense to include these as patches to
>>>>> different Jira issues just in case one or more of them need to be
>>>>> discussed first.
>>>>
>>>> Ok, I'll open 2-3 issues with small patches.
>>>>
>>>>> As for the javadoc, I just added that back really quickly before our
>>>>> first maven deployment to ensure that it would be uploaded. For some
>>>>> reason the previous configuration didn't seem to be generating it at
>>>>> all. Where should it go? I personally don't really care how it is
>>>>> defined as long as it is generated and uploaded each time a deployment
>>>>> is done. Any patches/recommendations for that?
>>>>
>>>> By default javadoc:jar binds to package phase, which is the
>>>> recommended usage. However, it takes some time and the most common
>>>> Maven command is mvn install so it makes sense to try to optimize the
>>>> execution time of it. For one project at work the javadoc is created
>>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>>> install. However, the most common way to do it is to generate javadoc
>>>> as part of site deployment (I think site plugin executes it even by
>>>> default). We could do it with a profile for now while we think about
>>>> the site deployment some more (as part of the other email thread).
>>>> I'll create an issue and add a patch.
>>>>
>>>> Kalle
>>>>
>>>>
>>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>>> Korhonen<ka...@gmail.com> wrote:
>>>>>> There are a few small errors in the trunk and some and some
>>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>>> nice so nothing would mask the real errors), but would the committers
>>>>>> accept it, and if so, should I open an issue for each of them
>>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>>
>>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>>> to declare org.apache.shiro (not org.shiro).
>>>>>> - all target folders need to be added to svn:ignore
>>>>>> - IDE specific files should be added to svn:ignore
>>>>>> - why is javadoc generated as part of regular install goal?
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
Issue and patch for the javadoc profile:
https://issues.apache.org/jira/browse/SHIRO-88
Kalle
PS. I also see some unstable/unreliable tests, maybe I can harden them a bit...
On Mon, Aug 24, 2009 at 4:16 PM, Kalle
Korhonen<ka...@gmail.com> wrote:
> The usual way is deploy the site and publish javadocs as part of the
> site. If not that, then the alternative is invoking it via a profile.
> mvn -P javadoc deploy would work just the same (the current javadoc
> plugin configuration would just move to the profile, no other changes
> needed).
>
> Kalle
>
> On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
>> Great, thanks very much for this Kalle.
>>
>> +1 to removing the JavaDoc as part of the install process to shorten
>> build times. I wouldn't want to move it to a profile until we can
>> also guarantee it executes during the deploy goal so the build server
>> produces them during the normal deployment. I'm sure this is an easy
>> fix that I'm overlooking...
>>
>> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
>> Korhonen<ka...@gmail.com> wrote:
>>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>>> I'd be happy to add any patches you might be able to contribute. I
>>>> agree that there is still some cleanup left like what you recommend.
>>>> I think it might make more sense to include these as patches to
>>>> different Jira issues just in case one or more of them need to be
>>>> discussed first.
>>>
>>> Ok, I'll open 2-3 issues with small patches.
>>>
>>>> As for the javadoc, I just added that back really quickly before our
>>>> first maven deployment to ensure that it would be uploaded. For some
>>>> reason the previous configuration didn't seem to be generating it at
>>>> all. Where should it go? I personally don't really care how it is
>>>> defined as long as it is generated and uploaded each time a deployment
>>>> is done. Any patches/recommendations for that?
>>>
>>> By default javadoc:jar binds to package phase, which is the
>>> recommended usage. However, it takes some time and the most common
>>> Maven command is mvn install so it makes sense to try to optimize the
>>> execution time of it. For one project at work the javadoc is created
>>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>>> install. However, the most common way to do it is to generate javadoc
>>> as part of site deployment (I think site plugin executes it even by
>>> default). We could do it with a profile for now while we think about
>>> the site deployment some more (as part of the other email thread).
>>> I'll create an issue and add a patch.
>>>
>>> Kalle
>>>
>>>
>>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>>> Korhonen<ka...@gmail.com> wrote:
>>>>> There are a few small errors in the trunk and some and some
>>>>> folders/files that would need to be ignore from svn. I could easily
>>>>> write up a patch to clean it up (I like my source tree all clean and
>>>>> nice so nothing would mask the real errors), but would the committers
>>>>> accept it, and if so, should I open an issue for each of them
>>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>>> with commit rights would do them directly. Here's a few for reference:
>>>>>
>>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>>> to declare org.apache.shiro (not org.shiro).
>>>>> - all target folders need to be added to svn:ignore
>>>>> - IDE specific files should be added to svn:ignore
>>>>> - why is javadoc generated as part of regular install goal?
>>>>>
>>>>> Kalle
>>>>>
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
The usual way is deploy the site and publish javadocs as part of the
site. If not that, then the alternative is invoking it via a profile.
mvn -P javadoc deploy would work just the same (the current javadoc
plugin configuration would just move to the profile, no other changes
needed).
Kalle
On Mon, Aug 24, 2009 at 7:37 AM, Les Hazlewood<lh...@apache.org> wrote:
> Great, thanks very much for this Kalle.
>
> +1 to removing the JavaDoc as part of the install process to shorten
> build times. I wouldn't want to move it to a profile until we can
> also guarantee it executes during the deploy goal so the build server
> produces them during the normal deployment. I'm sure this is an easy
> fix that I'm overlooking...
>
> On Mon, Aug 24, 2009 at 10:30 AM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>>> I'd be happy to add any patches you might be able to contribute. I
>>> agree that there is still some cleanup left like what you recommend.
>>> I think it might make more sense to include these as patches to
>>> different Jira issues just in case one or more of them need to be
>>> discussed first.
>>
>> Ok, I'll open 2-3 issues with small patches.
>>
>>> As for the javadoc, I just added that back really quickly before our
>>> first maven deployment to ensure that it would be uploaded. For some
>>> reason the previous configuration didn't seem to be generating it at
>>> all. Where should it go? I personally don't really care how it is
>>> defined as long as it is generated and uploaded each time a deployment
>>> is done. Any patches/recommendations for that?
>>
>> By default javadoc:jar binds to package phase, which is the
>> recommended usage. However, it takes some time and the most common
>> Maven command is mvn install so it makes sense to try to optimize the
>> execution time of it. For one project at work the javadoc is created
>> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
>> install. However, the most common way to do it is to generate javadoc
>> as part of site deployment (I think site plugin executes it even by
>> default). We could do it with a profile for now while we think about
>> the site deployment some more (as part of the other email thread).
>> I'll create an issue and add a patch.
>>
>> Kalle
>>
>>
>>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>>> Korhonen<ka...@gmail.com> wrote:
>>>> There are a few small errors in the trunk and some and some
>>>> folders/files that would need to be ignore from svn. I could easily
>>>> write up a patch to clean it up (I like my source tree all clean and
>>>> nice so nothing would mask the real errors), but would the committers
>>>> accept it, and if so, should I open an issue for each of them
>>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>>> with commit rights would do them directly. Here's a few for reference:
>>>>
>>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>>> to declare org.apache.shiro (not org.shiro).
>>>> - all target folders need to be added to svn:ignore
>>>> - IDE specific files should be added to svn:ignore
>>>> - why is javadoc generated as part of regular install goal?
>>>>
>>>> Kalle
>>>>
>>>
>>
>
Re: Trunk clean-up?
Posted by Les Hazlewood <lh...@apache.org>.
Great, thanks very much for this Kalle.
+1 to removing the JavaDoc as part of the install process to shorten
build times. I wouldn't want to move it to a profile until we can
also guarantee it executes during the deploy goal so the build server
produces them during the normal deployment. I'm sure this is an easy
fix that I'm overlooking...
On Mon, Aug 24, 2009 at 10:30 AM, Kalle
Korhonen<ka...@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
>> I'd be happy to add any patches you might be able to contribute. I
>> agree that there is still some cleanup left like what you recommend.
>> I think it might make more sense to include these as patches to
>> different Jira issues just in case one or more of them need to be
>> discussed first.
>
> Ok, I'll open 2-3 issues with small patches.
>
>> As for the javadoc, I just added that back really quickly before our
>> first maven deployment to ensure that it would be uploaded. For some
>> reason the previous configuration didn't seem to be generating it at
>> all. Where should it go? I personally don't really care how it is
>> defined as long as it is generated and uploaded each time a deployment
>> is done. Any patches/recommendations for that?
>
> By default javadoc:jar binds to package phase, which is the
> recommended usage. However, it takes some time and the most common
> Maven command is mvn install so it makes sense to try to optimize the
> execution time of it. For one project at work the javadoc is created
> as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
> install. However, the most common way to do it is to generate javadoc
> as part of site deployment (I think site plugin executes it even by
> default). We could do it with a profile for now while we think about
> the site deployment some more (as part of the other email thread).
> I'll create an issue and add a patch.
>
> Kalle
>
>
>> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
>> Korhonen<ka...@gmail.com> wrote:
>>> There are a few small errors in the trunk and some and some
>>> folders/files that would need to be ignore from svn. I could easily
>>> write up a patch to clean it up (I like my source tree all clean and
>>> nice so nothing would mask the real errors), but would the committers
>>> accept it, and if so, should I open an issue for each of them
>>> separately or one for all? It'd cut down on bureaucracy if somebody
>>> with commit rights would do them directly. Here's a few for reference:
>>>
>>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>>> to declare org.apache.shiro (not org.shiro).
>>> - all target folders need to be added to svn:ignore
>>> - IDE specific files should be added to svn:ignore
>>> - why is javadoc generated as part of regular install goal?
>>>
>>> Kalle
>>>
>>
>
Re: Trunk clean-up?
Posted by Kalle Korhonen <ka...@gmail.com>.
On Mon, Aug 24, 2009 at 6:22 AM, Les Hazlewood<lh...@apache.org> wrote:
> I'd be happy to add any patches you might be able to contribute. I
> agree that there is still some cleanup left like what you recommend.
> I think it might make more sense to include these as patches to
> different Jira issues just in case one or more of them need to be
> discussed first.
Ok, I'll open 2-3 issues with small patches.
> As for the javadoc, I just added that back really quickly before our
> first maven deployment to ensure that it would be uploaded. For some
> reason the previous configuration didn't seem to be generating it at
> all. Where should it go? I personally don't really care how it is
> defined as long as it is generated and uploaded each time a deployment
> is done. Any patches/recommendations for that?
By default javadoc:jar binds to package phase, which is the
recommended usage. However, it takes some time and the most common
Maven command is mvn install so it makes sense to try to optimize the
execution time of it. For one project at work the javadoc is created
as part of "javadoc" profile, i.e. you execute it with mvn -P javadoc
install. However, the most common way to do it is to generate javadoc
as part of site deployment (I think site plugin executes it even by
default). We could do it with a profile for now while we think about
the site deployment some more (as part of the other email thread).
I'll create an issue and add a patch.
Kalle
> On Sat, Aug 22, 2009 at 11:53 PM, Kalle
> Korhonen<ka...@gmail.com> wrote:
>> There are a few small errors in the trunk and some and some
>> folders/files that would need to be ignore from svn. I could easily
>> write up a patch to clean it up (I like my source tree all clean and
>> nice so nothing would mask the real errors), but would the committers
>> accept it, and if so, should I open an issue for each of them
>> separately or one for all? It'd cut down on bureaucracy if somebody
>> with commit rights would do them directly. Here's a few for reference:
>>
>> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
>> to declare org.apache.shiro (not org.shiro).
>> - all target folders need to be added to svn:ignore
>> - IDE specific files should be added to svn:ignore
>> - why is javadoc generated as part of regular install goal?
>>
>> Kalle
>>
>
Re: Trunk clean-up?
Posted by Les Hazlewood <lh...@apache.org>.
Hi Kalle,
I'd be happy to add any patches you might be able to contribute. I
agree that there is still some cleanup left like what you recommend.
I think it might make more sense to include these as patches to
different Jira issues just in case one or more of them need to be
discussed first.
As for the javadoc, I just added that back really quickly before our
first maven deployment to ensure that it would be uploaded. For some
reason the previous configuration didn't seem to be generating it at
all. Where should it go? I personally don't really care how it is
defined as long as it is generated and uploaded each time a deployment
is done. Any patches/recommendations for that?
Cheers,
Les
On Sat, Aug 22, 2009 at 11:53 PM, Kalle
Korhonen<ka...@gmail.com> wrote:
> There are a few small errors in the trunk and some and some
> folders/files that would need to be ignore from svn. I could easily
> write up a patch to clean it up (I like my source tree all clean and
> nice so nothing would mask the real errors), but would the committers
> accept it, and if so, should I open an issue for each of them
> separately or one for all? It'd cut down on bureaucracy if somebody
> with commit rights would do them directly. Here's a few for reference:
>
> - package-info.java in shiro-core/src/main/java/org/apache/shiro needs
> to declare org.apache.shiro (not org.shiro).
> - all target folders need to be added to svn:ignore
> - IDE specific files should be added to svn:ignore
> - why is javadoc generated as part of regular install goal?
>
> Kalle
>