That's a good point, but is the extra configuration worth the hassle? I
mean, generating a site seems pretty normal to me. Perhaps Maven should just
have the plugin handy anyway?
Paul
On Wed, Aug 11, 2010 at 7:46 PM, Brett Porter wrote:
>
> On 12/08/2010, at 10:30 AM, Paul Benedict wrote:
>
> >
On 12/08/2010, at 10:30 AM, Paul Benedict wrote:
> As an analogy, the source:jar command doesn't do anything for non-jar
> projects. Couldn't something similar be done that when no site descriptor
> exists, no site is generated? Otherwise, presto.
That's how it works, but it still has to drag do
As an analogy, the source:jar command doesn't do anything for non-jar
projects. Couldn't something similar be done that when no site descriptor
exists, no site is generated? Otherwise, presto.
Paul
On Wed, Aug 11, 2010 at 6:45 PM, Brett Porter wrote:
>
> On 12/08/2010, at 9:08 AM, Paul Benedict
On 12/08/2010, at 9:08 AM, Paul Benedict wrote:
> I asked Oliver why the aforementioned goal "was removed from the built-in
> lifecycle bindings for projects with packaging pom"? He said the decision
> was to remove all reporting stuff from trunk.
>
> I thought the decision was to remove reporti
I asked Oliver why the aforementioned goal "was removed from the built-in
lifecycle bindings for projects with packaging pom"? He said the decision
was to remove all reporting stuff from trunk.
I thought the decision was to remove reporting logic from Maven's core? I
don't see why the site plugin
What I saw is some of those staged artifacts were missing signatures.
Nexus works correctly, it only complained the missing ones, not all.
On Wed, Jan 13, 2010 at 2:32 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> 2010/1/13 Brian Fox :
> > We should definitely fix this, both in
2010/1/13 Brian Fox :
> We should definitely fix this, both in the GPG and in Nexus. Currently
> it expects all files to be signed and this is the first one we've come
> across that wasn't signed. I'll disable the rule now until it's sorted
> out and close the repo for you.
>
> Stephen, what ended
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 ca
We should definitely fix this, both in the GPG and in Nexus. Currently
it expects all files to be signed and this is the first one we've come
across that wasn't signed. I'll disable the rule now until it's sorted
out and close the repo for you.
Stephen, what ended up being the fix for the rest of
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
On Tue, Jan 12, 2010 at 9:43 AM, Stephen Connolly
wrote:
> For some reason the site descriptor does not get a signature generated
> by the gpg plugin.
>
> As r.a.o now requires all artifacts to be signed, it would appear to
> be impossible to close a staged repository.
If it's going in the repo,
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
On 13/01/2010, at 4:59 AM, Daniel Kulp wrote:
>
> Why is the site descriptor being generated for surefire?
Because it has an inherited site descriptor to share across the subprojects:
http://svn.apache.org/viewvc/maven/surefire/tags/surefire-2.5/src/site/site.xml?view=log
For Stephen to work
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)
inh
Look at the POM lifecycle. The site stuff is wedged in there. I removed this in
3.x.
http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.0/maven-core/src/main/resources/META-INF/plexus/components.xml
On 2010-01-12, at 12:59 PM, Daniel Kulp wrote:
>
> Why is the site descriptor being g
Then project site generation will be borked (even more than usual)
I've no issues using 3.0-SNAPSHOT
2010/1/12 Jason van Zyl :
> You can use 3.x, I removed the site stuff from the lifecycle :-)
>
> On 2010-01-12, at 12:42 PM, Stephen Connolly wrote:
>
>> Fair enough, but we cannot make releases a
Why is the site descriptor being generated for surefire?
The shade release two weeks ago didn't generate a site file:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-shade-plugin/1.3/
and neither did the patch plugin:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-patc
You can use 3.x, I removed the site stuff from the lifecycle :-)
On 2010-01-12, at 12:42 PM, Stephen Connolly wrote:
> Fair enough, but we cannot make releases as things currently stand
>
> 2010/1/12 Jason van Zyl :
>> The site stuff needs to be completely decoupled from releases. It such a
>>
The root cause seems to be that m-gpg-p does not consider that
project.artifact may have multiple entries (specifically the site
metadata)
We can argue that the site needs to be decoupled from releasing, but
as the site descriptor is one of the artifacts of a project (as
opposed to the site) then
Fair enough, but we cannot make releases as things currently stand
2010/1/12 Jason van Zyl :
> 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 sepa
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.
On 2010-01-12, at 12:08 PM, Daniel Kulp wrote:
>
> Why does the site descriptor need to be
Why does the site descriptor need to be "released" as part of the plugin? Why
not release surefire without it?
It's definitely a bug, but I'm failing to see why it's a blocker for now.
Dan
On Tue January 12 2010 11:56:28 am Stephen Connolly wrote:
> I've raised http://jira.codehaus.org/
I've raised http://jira.codehaus.org/browse/MGPG-19 to track the root cause.
A temporary work around would be to disable GPG validation on r.a.o
-Stephen
P.S.
I'm blocked from releasing Surefire 2.5 due to this issue
2010/1/12 Stephen Connolly :
> For some reason the site descriptor does not g
For some reason the site descriptor does not get a signature generated
by the gpg plugin.
As r.a.o now requires all artifacts to be signed, it would appear to
be impossible to close a staged repository.
Or do other people have information to the contrary?
-Stephen
--
I reproduced it with 2.0.7. I know exactly how to make an IT test for
this so I will work on that when I get some time.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 20, 2007 6:56 PM
To: Maven Developers List
Subject: Re: site:attach-descriptor
On 21/09/2007, at 8:44 AM, Brian E. Fox wrote:
I noticed a while back that the attach-descriptor is included in the
default lifecycle. Is this really needed for non-pom projects?
Yeah, only makes sense for pom projects I think.
Also there is something bigger going on. Recently 2.0-SNAPSHOT
I noticed a while back that the attach-descriptor is included in the
default lifecycle. Is this really needed for non-pom projects?
Also there is something bigger going on. Recently 2.0-SNAPSHOT of the
site plugin was added as a dependency to the dependency plugin. When the
dependency plugin is
Hi all,
In the documentation for site:attach-descriptor at
http://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html,
the only meaningful docs are the sentence:
"Adds the site descriptor to the list of files to be installed/deployed."
This suggests that this goal
28 matches
Mail list logo
