The cleanup is done. Summary of
changes:
Plugins were renamed to mojo standard -
"xxx-maven-plugin"
Mojo-sandbox parent created. This parent uses a snapshot
revision. Since everything using it is also a snapshot, this will be accessible
from the same repository. It also allows the ability to stop accidental ibiblio
releases from the sandbox by redirecting the repo1
repository.
Mojo Parent 6 created and deployed.
Javadoc and Changes report added to Mojo
parent.
Sandbox Plugin sites deployed and Mojo Site updated with
new links. Plugins that couldn't be site:deployed have urls to the svn
repository. At least they can be seen and found this way
even w/o a site.
Mojo Development section updated to help new
users.
Sandbox plugins that weren't previously deployed now have
snapshots deployed.
Notes:
Cobertura site not deployed because of permissions
problem.
Minijar crashes site plugin.
There are a couple of plugins still using org.apache.maven
as the package
(apidocs,deb,eve,groovy-tools,jboss-sar,jdbc,rmic)
Some plugins couldn't be built because of missing
dependencies, compile issues,etc. These are noted in the mojo-sandbox pom
modules section.
I think that's it. Hopefully I improved more than I broke,
if not it's because I was distracted by Jason's concrete countertops.
;-)
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Friday, January 13, 2006 7:44 PM
To: dev@mojo.codehaus.org
Subject: RE: [mojo-dev] [vote] Sandbox cleanup
Final Tally:
1a.
Should we create a mojo-sandbox parent and have sandbox plugins derive from
here? This way we can set the scm urls and anything else that comes along here.
Only the parent section would need to change when a plugin graduates from the
sandbox.
+1 Kris, Carlos,Dan,Brett
1b.
Keep deriving from mojo parent, but add instructions to site to tell devs how to
override the scm connection when added to sandbox and add instructions to
guidelines for release to have devs remember to remove the override when
graduating.
-1 Kris,
2.
Should we correct the plugin names?
+1 Kris,Carlos,Dan,Brett
3.
Should all sandbox plugins be added to the mojo sandbox
site?
+1 Kris, Carlos,Dan,Brett
Additionally:
Brett suggested demoting plugins to the
sandbox that haven't been released. This would be -Jboss and Jspc that are
trying to do releases shortly.
So I will begin working this over the
weekend. First by renaming the plugins, then adding the sandbox parent, then
updating the sites and releasing snapshots. I'll hold on the demotion until the
vote on moving some mojos to apache is finalized to avoid redundant work.
I'll need to deploy the sandbox parent
before I can deploy the snapshots, I might need help with permissions on that
part.
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 9:07 PM
To: dev@mojo.codehaus.org
Subject: [mojo-dev] [vote] Sandbox cleanup
I've been looking at
some plugins in the sandbox and I see some issues:
1. If sandbox
plugins deploy sites, (as they probably should so they get some visability), the
scm connections are wrong because they inherit from the mojo
parent.
2. Some plugins have
the name maven-xxx-plugin instead of xxx-maven-plugin
3. Many plugins
aren't even posted on the mojo site.
I'd like to have a
vote on these issues:
1a. Should we create
a mojo-sandbox parent and have sandbox plugins derive from here? This way we can
set the scm urls and anything else that comes along here. Only the parent
section would need to change when a plugin graduates from the
sandbox.
-
OR-
1b. Keep deriving
from mojo parent, but add instructions to site to tell devs how to override the
scm connection when added to sandbox and add instructions to guidelines for
release to have devs remember to remove the override when
graduating.
2. Should we correct
the plugin names?
3. Should all
sandbox plugins be added to the mojo sandbox site?
Thx.
