> Let children have sparse scm, and make it the job of the
> scm provider, at runtime ...
Thought about that too. That would work for maven-scm, but there are lots of
other plugins and extensions which access the URL information too. For example
the site-reporting plugin uses it to report the SC
Mark,
Oh, drat, I see, to pick a provider, we have to have finished
processing extensions and all that other good model-building stuff.
OK, another thought.
As per a previous comment in this thread, death to inheritance in scm.
Let children have sparse scm, and make it the job of the scm provide
The Model gets constructed and only if that step is finished, all the
information to determine the correct scm provider GAV is available!
But at this point in time it's too late to modify the SCM url because afaik the
Model cannot get amended, right?
At least that's what I remember from grabbin
Mark,
I only see a cycle if the scm modules have to call back into the model
to get the facts they need to answer the question the model is asking.
If the model can load all of the scm facts for the current project and
its parents into some data structure and pass it into the scm to ask
it to fill
Hi folks!
Just back from vacation so I try to slowly catch up speed ...
There are a few things to take care off:
a.) We must not introduce a circle: model -> scm -> model. In other words: we
cannot ask the scm provider to give us additional information to build the
model before the model has b
yes, that would be a good option and seems reasonable from my perspective
Le dimanche 17 juillet 2011, Benson Margulies a écrit :
> Well, I'm not a PMC member, so I'll just follow instructions. Someone
> might wonder if, given the progressive calm that has settled over the
> trademark business, pe
Vincent S did a lot of work on JXR, and has a branch in sandbox
He's actually on holiday and should reply when he's back to make the good
choice
Regards,
Hervé
Le dimanche 17 juillet 2011, Benson Margulies a écrit :
> For the next release, how would you feel about moving the plugin in
> with th
For the next release, how would you feel about moving the plugin in
with the other plugins, and eliminating the extra level of parent?
On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMY wrote:
> for the old aggregation parameter, it's easy
> for the goals documentation, yes, I don't understand how it
Well, I'm not a PMC member, so I'll just follow instructions. Someone
might wonder if, given the progressive calm that has settled over the
trademark business, perhaps Sonatype might go back to dual-licensing
if asked?
On Sat, Jul 16, 2011 at 5:36 PM, Hervé BOUTEMY wrote:
> Good question :)
>
> C
Good question :)
Current Maven versions (3.0.3 and 3.0.4-SNAPSHOT) use Aether 1.11, which has a
dual EPL/ASLv2 license [1].
As far new versions of Aether stay under ASLv2 license, there is no question
for Maven when upgrading dependency.
Now, Aether 1.12 was released under EPL license only, and
I'll come looking for assistance once the vote passes.
On Sat, Jul 16, 2011 at 4:09 PM, Hervé BOUTEMY wrote:
> for the old aggregation parameter, it's easy
> for the goals documentation, yes, I don't understand how it can disappear. It
> seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe yo
for the old aggregation parameter, it's easy
for the goals documentation, yes, I don't understand how it can disappear. It
seems to be using m-site-p 2.2: upgrade to 2.3? Or maybe you changed the
parent? We're a few working on site improvements to avoid regressions with
future releases: site ITs
By the way, is anyone still active who did the previous release of
JXR? It's not obvious how I could have caused these issues.
On Sat, Jul 16, 2011 at 3:36 PM, Hervé BOUTEMY wrote:
> qhat I usually do is patch the trunk
> and when publishing the final version, I copy modified files from site to m
qhat I usually do is patch the trunk
and when publishing the final version, I copy modified files from site to my
local checkout
yes, that means that the site published on maven.apache.org isn't reproducible
But having a non-reproducible site isn't really an issue AFAIK
modifying the svn tag woul
Folks,
I've submitted one tiny fix to Aether, and I have a feature proposal
I'm discussing with the proprietor: making the *-pattern in mirrors a
bit richer.
Eventually, this would be 'as simple' as a change to the aether
provider to take a newer aether. However, I wonder if the PMC has
establish
Hervé,
How can I make these site repairs when publishing against the label?
Is the idea to go ahead and make fixes to a checkout of the tag,
publish the site, and then patch them into trunk?
--benson
On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY wrote:
> +1
>
> tested in Maven 3.0.4-SNAPSHOT
+1
tested in Maven 3.0.4-SNAPSHOT [1] (sync pending)
notice that there are some glitches with documentation:
- plugin-info.html isn't there nor goals documentation (?)
- aggregating example should be modified like javadoc to show new goals and
mark aggregate parameter as obsolete
nothing that pr
17 matches
Mail list logo
