Clean with the -Papps switch did the trick.
I'll finish up on the Tiles stufff, deploy the applications, and post
a new all-snapshot.
I also need to put the menubar references back for scripting and
tiles. Evidentally, beta4 doesn't inherit these, but beta5 does. But
overall, it looks like b4 is
On 7/12/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On 7/12/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> > Is there something we want in beta5, aside from site:run, or can we
> > use beta4 for this release?
>
> Not that I know of. Yes, maven-si
On 7/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 7/12/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> Is there something we want in beta5, aside from site:run, or can we
> use beta4 for this release?
Not that I know of. Yes, maven-site-plugin 2.0-beta4 should be fine.
Sigh. I tried to build
On 7/12/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Is there something we want in beta5, aside from site:run, or can we
use beta4 for this release?
Not that I know of. Yes, maven-site-plugin 2.0-beta4 should be fine.
PS: I filed http://jira.codehaus.org/browse/MSITE-159
Thanks. :)
--
Wendy
On 7/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
If we're going to split it up, I think we should drop the -all
distribution. Upload what you want them to look like and I'll see
about adjusting the assembly descriptors to match.
Just make each subdirectory in the "all" assembly a separate ar
On 7/12/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
Try going back to maven-site-plugin 2.0-beta4 by changing the plugin
version in the parent pom, and see if that helps.
Yes, that does help. The issue also goes away.
Is there something we want in beta5, aside from site:run, or can we
use beta
On 7/12/06, Ted Husted <[EMAIL PROTECTED]> wrote:
BUT, for the 4 Jul snapshot we didn't need to do this, so why do I
have to do it now?
(I actually like doing it, since it's our URI, so we can afford to be
specific, and being specific saves a redirect. But why is my snapshot
different?)
Try g
On 7/11/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
It's (somehow) related to the // in
the pom. It took me a few tries to get the links on the Tiles 2 site
to work. If the directory name on the site matches the artifactId in
the pom, it works as designed. If not, you have to add elements
to f
On 7/11/06, Don Brown <[EMAIL PROTECTED]> wrote:
So basically we'd add an empty directory in all cases?
No, I meant:
Website:
struts.apache.org/1.x -> struts.apache.org/struts1
struts.apache.org/2.0 > struts.apache.org/struts2
Repository:
struts/struts1/apps -> struts/struts1/struts-apps
str
Ted Husted wrote:
I'd really prefer that we use one set of naming conventions. If it's
more typing, then so be it. I've already typed a year's worth of URIs
in this email message :)
My suggestion is that we make it a straight-line correlation
Website
/s/1.x/struts1
/s/2.0/struts2
Repository
/s
On 7/11/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
It's (somehow) related to the // in
the pom. It took me a few tries to get the links on the Tiles 2 site
to work. If the directory name on the site matches the artifactId in
the pom, it works as designed. If not, you have to add elements
to f
On 7/11/06, Don Brown <[EMAIL PROTECTED]> wrote:
I dunno: /repos/asf/struts/struts1/struts-core ... that's a lot of Struts and
too much typing, IMO. The only reason the artifact id's have "struts-" in them
is for the jar names. Otherwise, I'd say the group id having Struts in it would
be fine.
I dunno: /repos/asf/struts/struts1/struts-core ... that's a lot of Struts and
too much typing, IMO. The only reason the artifact id's have "struts-" in them
is for the jar names. Otherwise, I'd say the group id having Struts in it would
be fine.
Don
Wendy Smoak wrote:
On 7/11/06, Ted Hust
Oh, you are talking about svn. Ignore me :)
Don
Don Brown wrote:
The web site directory already matches the artifact id, IIRC. I
thought your original complaint was about how Maven dealt with the
/1.x prefix.
Don
On 7/11/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/11/06, Wendy Smoak <[E
On 7/11/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Do we want to go with the flow and change the directory names then?
If we are using "struts-scripting" on the website, it makes more sense
to me to use "struts-scripting" in the repository.
Changing the directory names in the svn repo isn't go
The web site directory already matches the artifact id, IIRC. I
thought your original complaint was about how Maven dealt with the
/1.x prefix.
Don
On 7/11/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 7/11/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> It's (somehow) related to the // in
> the p
On 7/11/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
It's (somehow) related to the // in
the pom. It took me a few tries to get the links on the Tiles 2 site
to work. If the directory name on the site matches the artifactId in
the pom, it works as designed. If not, you have to add elements
to f
On 7/11/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
If the directory name on the site matches the artifactId in
the pom, it works as designed.
s/designed/desired. I assume it's working as designed, even if I'm
not quite sure what the design is...
--
Wendy
-
On 7/11/06, Ted Husted <[EMAIL PROTECTED]> wrote:
I don't know what I'm doing wrong, but the menu URIs on the subsites
are not rendering correctly for me.
For some reason, they seem to be stripping
"http://struts.apache.org/"; out of all the URIs, so that a reference
to "http://struts.apache.or
I don't know what I'm doing wrong, but the menu URIs on the subsites
are not rendering correctly for me.
For some reason, they seem to be stripping
"http://struts.apache.org/"; out of all the URIs, so that a reference
to "http://struts.apache.org/1.x"; becomes "1.x", and a reference to
just "http
20 matches
Mail list logo
