Problem with WindupConfigModel
by Ondrej Zizka
Problem with WindupConfigModel is that *currently* it needs context
initialized, since it is initialized like this:
WindupConfigurationModel config =
GraphService.getConfigurationModel(context);
And at the same time this config "DTO" needs to be passed into the
top-level API (currently WindupProcessor).
I can see 2 solutions:
A) Continue using WCM, implement WINDUP-147 GraphService.merge()
to store classes implementing the model interface
so that supports adjacent models (needed for the scan packages)
B) Have WindupConfig, and copy stuff to WCM (which is the same as A,
only done manually)
C) What I am currently doing, an ugly hack - passing final variables
into GraphLifecycleListener
Ondra
9 years, 9 months
Refactoring merge?
by Ondrej Zizka
Hi,
The refactoring for WINDUP-272
<https://issues.jboss.org/browse/WINDUP-272> and WINDUP-274
<https://issues.jboss.org/browse/WINDUP-274> is done.
However, it changed so many files, that I would need another few days to
merge.
The commits after the structural changes just changed few files, so I
suggest:
Let's merge my PR, then do the changes again (it's just few dir move
steps), and put the rest of the commits on top of that.
Ondra
PS: It would be COOL if such structural changes would be done when we
don't expect a big commit.
9 years, 9 months
Fwd: Re: GitHub problem rendering AsciiDoc lists
by Sande Gilda
Ondra, I reported the issue you brought up where GitHub renders AsciiDoc
list items with a paragraph tag. It looks like they are going to address
it. :-)
-------- Original Message --------
Subject: Re: GitHub problem rendering AsciiDoc lists
Date: Thu, 11 Sep 2014 03:18:00 -0700
From: Jess Hosman (GitHub Staff) <support(a)github.com>
To: Sande Gilda <sgilda(a)redhat.com>
Hi Sande,
Thanks for pointing this out! I've opened an issue to let our developers know about it. If they have any questions, we'll hit you up for more information.
Cheers,
Jess
> GitHub renders Markdown list items correctly, but renders AsciiDoc list
items with a `<p></p>` tag. The resulting list has blank lines between
list items, resulting in a very spread out list.
> You can see examples here:
Markdown: https://github.com/sgilda/playground/blob/master/file-markdown.md
Asciidoc:
https://github.com/sgilda/playground/blob/master/file-asciidoc.asciidoc
Is this a stylesheet issue?
Thanks,
Sande Gilda
9 years, 9 months
Windup Meeting Minutes - 2014-09-10
by Lincoln Baxter, III
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Meeting summary
---------------
* Agenda (lincolnthree, 14:02:10)
* Windup general progress and priorities (lincolnthree, 14:37:19)
* Our release for Tech Preview is in TWENTY - 20 DAYS. (lincolnthree,
14:37:56)
* This includes documentation for RH associates to learn how to use
windup (lincolnthree, 14:38:20)
* It includes an actually working tool that doesn't run forever :)
(lincolnthree, 14:38:32)
* It must include feature parity with Windup 1 (lincolnthree,
14:38:45)
* It should be possible to write custom rules using our new API (I
think this is working) (lincolnthree, 14:39:12)
* We need: A reference guide, a presentation and a reproducible demo
of usage, as well as a presentation and demo of how to write rules.
(lincolnthree, 14:39:54)
* Those last things will probably be up to sgilda and robbg primarily,
with some help from us. (lincolnthree, 14:40:29)
* Status reports (lincolnthree, 14:04:28) * I have been working on
finishing up the port of visitors from the earlier "cdi" branch of windup
(jsightler, 14:06:20) * I am mostly done, but I am trying to get the class
file metadata over along with at least some method indexing (without too
much of a performance impact) (jsightler, 14:06:29) * Once that is
complete, I will work on putting some of this information into the reports,
and building queries to make the data actually useful (jsightler, 14:06:59)
* I've been working on WINDUP-104 - and have submitted a massive PR
updating about 318 files :p (lincolnthree, 14:09:38) * as part of this
issue, I've also refactored a few things (mostly around dependencies
between addons) (lincolnthree, 14:10:29) * I've also taken the opportunity
to add some tests for the reporting, to assert that we actually generate
something with content (lincolnthree, 14:11:40) * I've also reviewed a
number of PRs and been dealing with some crazy political fallout from our
"1 month release delay" (lincolnthree, 14:12:51) * I'm working on
refactoring of WindupProcessor, GraphContext/Factory, related tests.
(ozizka, 14:17:34) * I've observed interesting forge behavior WRT resolving
artifacts, which confused me a bit when changing between master and my
branch, and rebuilding (ozizka, 14:17:34) * I've also spend a while on CI -
but the job also fails due to the same Forge bug (ozizka, 14:17:34) *
Besides that, I'm documenting how the core works internally. (ozizka,
14:17:34) * I am also going to be working on the XML-config next (because
of some of this political stuff) - should be quick (lincolnthree, 14:20:32)
* Fixed the bug caused by java legacy rules. It is actually fun, because
they pointed out a bug in windup java file processing. The source java
files were not loaded to graph completely (opposed to binary java classes)
(mbriskar, 14:25:02) * XML legacy rules fully merged, however I am
suspicious of some problems caused by a lot of rebases. (mbriskar,
14:26:09) * LINK:
https://github.com/windup/windup/commit/700639f2eec5c7f997d7ee9b19c8e133f...
(jsightler, 14:28:51) * Trying to run the rexster embedded, so even during
the debugging there would be option to see how the graph looks like. This
is questionable, but I want to try (mbriskar, 14:32:38) * and also
implemented an option to run windup execution on one RuleProvider only (the
dependencies get counted).. this however is for discussion.. It is for
testing purposes (mbriskar, 14:34:34)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
9 years, 9 months
CDI question - producer
by Ondrej Zizka
Hi, with this
----------------------------------------------------------------
@Singleton
public class GraphContextFactoryImpl implements GraphContextFactory
{
@Inject
private GraphApiCompositeClassLoaderProvider
graphApiCompositeClassLoaderProvider;
@Inject
private Imported<Service<? extends VertexFrame>> graphServices;
@Inject
private GraphTypeRegistry graphTypeRegistry;
private GraphContext graphContext;
----------------------------------------------------------------
is there a difference between the following two?
Basically I just moved the core of the creation.
A is master, B is my branch, results in the GraphContext being created
at each @Inject.
I think I am missing something here.
Thanks, Ondra
---A-------------------------------------------------------------
@Override
public GraphContext create(){
return produceGraphContext();
}
@Produces @ApplicationScoped
public GraphContext produceGraphContext(){
if (this.graphContext == null){
this.graphContext = new GraphContextImpl(graphServices,
this.graphTypeRegistry, this.graphApiCompositeClassLoaderProvider);
}
return graphContext;
}
----B-----------------------------------------------------------
@Override
public GraphContext create() {
return new GraphContextImpl(
this.graphServices,
this.graphTypeRegistry,
this.graphApiCompositeClassLoaderProvider);
}
@Produces @ApplicationScoped
public GraphContext produceGraphContext(){
if (this.graphContext == null) {
this.graphContext = this.create();
}
return graphContext;
}
9 years, 9 months
Windup Jira Triage Meeting Log - 2014-09-04
by Lincoln Baxter, III
Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/windup/2014/windup....
Meeting summary
---------------
* WINDUP-90 closed as rejected (lincolnthree, 14:25:36)
* WINDUP-93 closed as done (lincolnthree, 14:28:34)
* WINDUP-99 closed as done (lincolnthree, 14:32:03)
* WINDUP-130 closed as done (lincolnthree, 14:47:25)
* WINDUP-140 closed as done (lincolnthree, 15:01:13)
* WINDUP-145 closed as rejected (lincolnthree, 15:05:37)
* WINDUP-187 closed as duplicate (lincolnthree, 15:56:09)
* WINDUP-189 closed as rejected (lincolnthree, 15:59:02)
* LINK: https://issues.jboss.org/browse/FORGE-1969 (lincolnthree,
16:16:52)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
9 years, 9 months
Wiki links trick for colon
by Ondrej Zizka
Hi all,
to save you some time figuring it out:
GitHub wiki doesn't like : in links, so a link to "Foo: Bar" may look
like this:
A) [blah](Foo%3A-Bar)
B) [blah](./Foo:-Bar)
C) [blah](./Foo: Bar)
D) If all fails - full URL.
HTH,
Ondra
9 years, 9 months
Bootstrapping in tests
by Ondrej Zizka
Hi all,
I've hit a problem with bootstrapping.
The tests grab the parts of windup through CDI and that initializes them
with defaults.
For example, JavaClassTest#testIterationVariableResolving():
The context initializes at the first line.
When processor.execute() is called, the graph was somehow reused before,
but that's just because of different code in all the execute() methods.
I could simply not set the output dir to WindupProcessorConfig, but the
output is not just where graph is.
I could also check if the graph already has been initialized, but 1)
that would make it nonconfigurable, 2) it would be nonsystemic -
checking in init code if a part of application being initialized was, by
accident, initialized somewhere else.
My suggestion is that we should have kind of bootstrap API for the
graph, similar to WindupProcessor - with a config class, and initialize
it from that.
I don't know how to combine that with CDI, so the tests would have to
use that API instead of CDI.
That's something I have suggested before, and was rejected, perhaps I
didn't explain it clearly back then.
I can't think up any other solution that I would not consider overkill,
like, some CDI providers of the config.
Any suggestions?
Ondra
-------------------------------------------------------------------------------
Test set: org.jboss.windup.rules.java.JavaClassTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 28.678
sec <<< FAILURE! - in org.jboss.windup.rules.java.JavaClassTest
testIterationVariableResolving(org.jboss.windup.rules.java.JavaClassTest) Time
elapsed: 5.346 sec <<< ERROR!
org.jboss.windup.util.exception.WindupException_$$_javassist_9c4de665-baa6-4904-a4d3-37530e41e5a0:
Error, attempting to set graph directory to:
"/home/ondra/work/Migration/Windup/rules/app/java/target/windup_5ba22a23-c85f-49f3-b01c-39fda0eb1faa/graph",
but the graph has already been initialized (with graph folder:
"/home/ondra/work/Migration/Windup/rules/app/java/target/windupgraph_1cfccd03-8f33-43a4-a305-99fdd38bc172"!
To change this, you must first disconnect from the graph!
at
org.jboss.windup.graph.GraphContextImpl.setGraphDirectory(GraphContextImpl.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
at
org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
at
org.jboss.weld.proxies.GraphContext$2110577583$Proxy$_$$_WeldClientProxy.setGraphDirectory(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
at
org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:40)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
at
org.jboss.windup.graph.GraphContext_$$_javassist_328a8426-f2d1-4f83-9490-e69b40a9c068.setGraphDirectory(GraphContext_$$_javassist_328a8426-f2d1-4f83-9490-e69b40a9c068.java)
at
org.jboss.windup.exec.WindupProcessorImpl.execute(WindupProcessorImpl.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor$1.call(ClassLoaderInterceptor.java:87)
at
org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:40)
at
org.jboss.forge.furnace.proxy.ClassLoaderInterceptor.invoke(ClassLoaderInterceptor.java:103)
at
org.jboss.windup.exec.WindupProcessorImpl_$$_javassist_5bf57ffb-10b3-495a-81bb-f630878e67e5.execute(WindupProcessorImpl_$$_javassist_5bf57ffb-10b3-495a-81bb-f630878e67e5.java)
at
org.jboss.windup.rules.java.JavaClassTest.testIterationVariableResolving(JavaClassTest.java:118)
9 years, 9 months
Status update - Decompiler - WINDUP-235
by Ondrej Zizka
Hi,
update on WINDUP-235:
Procyon's API is a bit low-level.
There's a package procyon-decompilertools, whose API is a bit weird and
tangled, and of course, without a bit of javadoc.
That package worked for .jar decompilation since that's the use case for
that package. Decompiling .class is not.
Procyon Wiki says it should be able to decompile a .class file, but it
is not - an ITypeLoader impl to get it from a filesystem is missing.
More, I think picking up from the .jar one by one would be slow.
I'm going to implement it so it would decompile files as accepted by a
filter, in one pass over given .jar.
Another approach is to move this to higher level, and when asked to
decompile "all classes in org.mycompany.*", query the graph for where
they are, and then decompile all classes from those jars, again, using a
filter.
Still, querying for all classes would be slow. So I suggest to store an
information about what jar contains which packages in the graph (if we
don't yet), WDYT?
And lastly - one idea - not sure how much time Windup spends on
comparing package prefixes, but we could build a package tree in the
graph when scanning, and when looking for classes from given package
org.foo.*, we could select with Gremlin:
PackageModel[name=org] -- contains --> PackageModel[name=foo] --
contains --> JavaClassModel .loop()
That could be faster when the numbers of classes in the projects get to
hundreds of thousands.
Ondra
9 years, 9 months