You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2010/01/12 23:52:29 UTC
Re: site descriptor and the lifecycle (was: repository.apache.org, gpg signatures and site:attach-descriptor)
On 13/01/2010, at 7:53 AM, Dennis Lundberg wrote:
> Jason van Zyl wrote:
>> The site stuff needs to be completely decoupled from releases. It such a horrible coupling and causes nothing but problems. Release and the documentation that goes along with it are completely separate.
>
> That might be so, but the site descriptor is needed for (site)
> inheritance reasons and therefor needs to be deployed to the repo.
Yep, that's right.
It's not actually coupled to the release, it is coupled to the POM lifecycle. I agree with Jason that that isn't the best, so probably in 3.0 that goal needs to be added to your POM by hand when you have a site descriptor to deploy (or the site plugin might change how it does things in some other way).
I don't agree with the statement "release and the documentation that goes along with it are completely separate", as I find that a useful way to work in general, and it is fundamental to publishing things like Javadoc and JXR, however it isn't really relevant to this problem as you've said.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: site descriptor and the lifecycle (was: repository.apache.org, gpg signatures and site:attach-descriptor)
Posted by Brett Porter <br...@apache.org>.
On 13/01/2010, at 1:23 PM, Jason van Zyl wrote:
>
> On 2010-01-12, at 5:52 PM, Brett Porter wrote:
>
>>
>> On 13/01/2010, at 7:53 AM, Dennis Lundberg wrote:
>>
>>> Jason van Zyl wrote:
>>>> The site stuff needs to be completely decoupled from releases. It such a horrible coupling and causes nothing but problems. Release and the documentation that goes along with it are completely separate.
>>>
>>> That might be so, but the site descriptor is needed for (site)
>>> inheritance reasons and therefor needs to be deployed to the repo.
>>
>> Yep, that's right.
>>
>
> No. It doesn't. I'm not planning on using the site plugin or Maven 3 and no one should have this stuff baked in by default. So now we can't use PGP validation because the site descriptor doesn't work which has nothing to do with trying to get the build deployed.
I think we've crossed the streams - Dennis is talking about about how it works today, with Maven 2.2.1 - something needs to be fixed for that. It looks like this was a bug in the way the site descriptor was attached (otherwise it could have affected other use cases you might consider more legitimate :)
As for Maven 3, I already agreed with you on decoupling it by default.
>
>> It's not actually coupled to the release, it is coupled to the POM lifecycle. I agree with Jason that that isn't the best, so probably in 3.0 that goal needs to be added to your POM by hand when you have a site descriptor to deploy (or the site plugin might change how it does things in some other way).
>>
>> I don't agree with the statement "release and the documentation that goes along with it are completely separate", as I find that a useful way to work in general, and it is fundamental to publishing things like Javadoc and JXR, however it isn't really relevant to this problem as you've said.
>>
>
> I'll qualify that and say completely separate actions. In many cases documentation is not necessarily generated by Maven. Another process may tie these things together but it should not happen in the build.
Sure... by default. Flipping to user mode - I would still like to use Maven to tie those things together, and in the instance where the documentation is generated by a Maven plugin (whether it be the site, dependency pulling docs from a repository, docbook, whatever), I'd like to retain the ability to have that in a single versioned build. Having them as some kind of sub-build where each is a separate action but you can still tie it all together is a possible alternative to the lifecycle interweaving mess.
But this is way off in the future stuff - as long as Maven 3 can still do what I do today in some way it's all good.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: site descriptor and the lifecycle (was: repository.apache.org, gpg signatures and site:attach-descriptor)
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2010-01-12, at 5:52 PM, Brett Porter wrote:
>
> On 13/01/2010, at 7:53 AM, Dennis Lundberg wrote:
>
>> Jason van Zyl wrote:
>>> The site stuff needs to be completely decoupled from releases. It such a horrible coupling and causes nothing but problems. Release and the documentation that goes along with it are completely separate.
>>
>> That might be so, but the site descriptor is needed for (site)
>> inheritance reasons and therefor needs to be deployed to the repo.
>
> Yep, that's right.
>
No. It doesn't. I'm not planning on using the site plugin or Maven 3 and no one should have this stuff baked in by default. So now we can't use PGP validation because the site descriptor doesn't work which has nothing to do with trying to get the build deployed.
> It's not actually coupled to the release, it is coupled to the POM lifecycle. I agree with Jason that that isn't the best, so probably in 3.0 that goal needs to be added to your POM by hand when you have a site descriptor to deploy (or the site plugin might change how it does things in some other way).
>
> I don't agree with the statement "release and the documentation that goes along with it are completely separate", as I find that a useful way to work in general, and it is fundamental to publishing things like Javadoc and JXR, however it isn't really relevant to this problem as you've said.
>
I'll qualify that and say completely separate actions. In many cases documentation is not necessarily generated by Maven. Another process may tie these things together but it should not happen in the build.
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org