nexus-indexer - caching nexus data between builds removed?
by Ondrej Zizka
Hi all,
original implementation of nexus indexer allowed to store nexus index
data outside project dir, ~/.something , to prevent downloading after
`mvn clean`.
After Lincoln's refactoring, it's not possible to rebuild the data
without redownloading the index.
Is that intentional? I think that we don't really need to redownload
maven index every time we clean target/ .
Right, Maven Indexer supports incremental updates, but that is broken
because of how metadataExists() is used.
Ondra
9 years, 3 months
Windup meeting minutes - 2015-02-11
by Lincoln Baxter, III
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2015/windup....
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2015/windup....
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2015/windup....
Meeting summary
---------------
* Agenda (lincolnthree, 15:09:05)
* Status Reports (lincolnthree, 15:10:43)
* I have been working on the SkipArchives and IdentifyArchives addon,
(ozizka, 15:12:52)
* it's done now, see PR's (ozizka, 15:12:58)
* The end of last week was in the sign of DevConf - I've prepared a
lab (ozizka, 15:13:20)
* I will reuse that stuff for a video which I have been planing for
long time (ozizka, 15:13:43)
* I've edited the wiki a bit (ozizka, 15:14:00)
* WINDUP-506 (ozizka, 15:14:33)
* Besides devconf I worked on WINDUP-489 (we provide rules that add
mappings from few files to xml files in rules dir), WINDUP-504
(XmlFile.in() now doesn't use pure regex but our type of regex)
(mbriskar, 15:15:33)
* I forgot - the @Rules metadata annotation (ozizka, 15:16:19)
* now I will try to focus on making our Java AST processing better
(catch superclasses/interfaces, maybe nested calls in the future)
(mbriskar, 15:16:29)
* So, that works and is ready for merge, only the categories do not
work, IDK why. (ozizka, 15:16:51)
* I spent most of last week finishing WINDUP-398 and WINDUP-456. They
are now merged. (lincolnthree, 15:18:12)
* I also reviewed several PRs, did some management catch-up.
(lincolnthree, 15:18:52)
* This week I will be working on our product integration plan, and
planning for the next release. (lincolnthree, 15:19:24)
* I worked on WINDUP-502 and WINDUP-503 (linking to EJB class files
and deployment descriptors when possible) (jsightler, 15:20:44)
* I have also worked on WINDUP-499 (displaying jar information in the
source report) (jsightler, 15:21:02)
* I also finished WINDUP-497, WINDUP-500, and WINDUP-501 (these are
related, and get us titles/bodies for inline hints, as well as
bodies in markdown format) (jsightler, 15:21:55)
* Priorities (lincolnthree, 15:24:44)
* To be discussed today during the planning meeting, but we will
likely spend a good amount of time for this release working on rules
metadata, externalization, and storage. possibly also on the AST
functionality (lincolnthree, 15:25:55)
* web UI rule generator (lincolnthree, 15:26:07)
* Web in general (lincolnthree, 15:38:21)
* Server config migration (lincolnthree, 15:45:06)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
9 years, 3 months
Windup Decorations vs Hints?
by Ian Tewksbury
Windup 1 used to have the idea of Decorations and of Hints. Lincoln pointed me in the direction of the InlineHintService which I am grabbing hints from. Is there still the idea of Decorations or did that distinction go away?
Blue Skies,
~Ian
9 years, 3 months
RuleProviders' / rules metadata
by Ondrej Zizka
Hi,
it seems that the metadata is a bit scattered around the place.
A) Some metadata are at rules themselves, e.g. as returned by
getExecuteAfter().
B) Some are sunken into the dark depth of ~.rewrite.Context, like
rewriteCtx.put(RuleMetadata.CATEGORY, DEFAULT_CATEGORY);
However when I try to retrieve this,
Object cat = event.getRewriteContext().get(RuleMetadata.CATEGORY);
I get null.
So I debugged and found the data stored in a weird data structure,
context.map[WindupRuleMetadata].providersToRules[?RuleProvider][?].contextMap
So I was trying to get it out,
WindupRuleMetadata wrm = (WindupRuleMetadata)
event.getRewriteContext().get(WindupRuleMetadata.class);
Assert.assertNotNull("event.getRewriteContext()[WindupRuleMetadata.class] is
not null", wrm);
for(WindupRuleProvider provider : wrm.getProviders())
{
if(provider.getClass().equals(TestMetadataAnnotationExecRuleProvider.class))
continue;
provider.get
}
But here I got lost as there seems to be no API for providersToRules.
1) How can I get to the metadata?
2) I suggest to review where and how the metadata are stored and unify
it a bit.
Thanks,
Ondra
PS: I admit that I didn't look much around for some working usages of
metadata as I am going to sleep, but CATEGORY seems not to be used anywhere.
9 years, 3 months
RuleProviders' / rules metadata
by "Ing. Ondřej Žižka"
Hi,
it seems that the metadata is a bit scattered around the place.
A) Some metadata are at rules themselves, e.g. as returned by
getExecuteAfter().
B) Some are sunken into the dark depth of ~.rewrite.Context, like
rewriteCtx.put(RuleMetadata.CATEGORY, DEFAULT_CATEGORY);
However when I try to retrieve this,
Object cat = event.getRewriteContext().get(RuleMetadata.CATEGORY);
I get null.
So I debugged and found the data stored in a weird data structure,
context.map[WindupRuleMetadata].providersToRules[?RuleProvider][?].contextMap
So I was trying to get it out,
WindupRuleMetadata wrm = (WindupRuleMetadata)
event.getRewriteContext().get(WindupRuleMetadata.class);
Assert.assertNotNull("event.getRewriteContext()[WindupRuleMetadata.class] is
not null", wrm);
for(WindupRuleProvider provider : wrm.getProviders())
{
if(provider.getClass().equals(TestMetadataAnnotationExecRuleProvider.class))
continue;
provider.get
}
But here I got lost as there seems to be no API for providersToRules.
1) How can I get to the metadata?
2) I suggest to review where and how the metadata are stored and unify
it a bit.
Thanks,
Ondra
PS: I admit that I didn't look much around for some working usages of
metadata as I am going to sleep, but CATEGORY seems not to be used anywhere.
9 years, 3 months
