[jira] [Commented] (DELTASPIKE-647) AppScoped abstract repositories doesn't work

2014-09-01 Thread Thomas Andraschko (JIRA)

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117196#comment-14117196
 ] 

Thomas Andraschko commented on DELTASPIKE-647:
--

Why do we need a default constructor in OWB?

Can we fix it with commons-proxy or do we need to switch to plain ASM?


 AppScoped abstract repositories doesn't work
 

 Key: DELTASPIKE-647
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-647
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Mark Struberg
 Attachments: 0001-Failing-PartialBeans-test.patch, 
 DELTASPIKE-647.patch, DS-647.7z






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Feedback on CMS with Github and Asciidoctor

2014-09-01 Thread Rafael Benevides

Hi John,

I believe that it's better to wait for the first contribution docs to 
arrive so we can rebase my branch to canonical master.


The idea is to avoid a folder that doesn't make sense (at least for now) ;)


Em 8/31/14, 17:19, John D. Ament escreveu:

Rafael,

So at this point, do you want to commit the new folder or do you want me to
take what I had done?  This currently makes it look like we don't even have
to ask infra to change our build script.  Nice.

John


On Thu, Aug 28, 2014 at 1:03 PM, Rafael Benevides benevi...@redhat.com
wrote:


I believe that the work for the asciidoc documentation is ready!

Please, check this generated asciidcotor page:
http://deltaspike.apache.org/documentation/container-control-test.html

The branch with the source code is here: https://github.com/rafabene/
deltaspike/tree/documentation/documentation


Em 8/27/14, 18:14, Rafael Benevides escreveu:

  Yeap. I have to agree with you.

So I've changed my strategy...

I've taken your PoC and made some minor modifications and place it on my
branch: https://github.com/rafabene/deltaspike/tree/documentation/
documentation

Note that I'm using the agreed path for documentation folder and that I
also included a Readme.md that instructs how to setup the credentials on
~/.m2/settings.xml and what maven command that should be used to deploy.

The result was published here: http://deltaspike.apache.org/
documentation/container-control-test.html

What is missing now is the generated html template/styles.


Em 8/27/14, 17:23, John D. Ament escreveu:


IMHO, the current approach is a bit safer and more testable.  running
mvn site will generate the asciidoc.  That would be a bit harder to do if
we need to support running it as a part of a staging pull.


On Wed, Aug 27, 2014 at 4:14 PM, Rafael Benevides benevi...@redhat.com
mailto:benevi...@redhat.com wrote:

 I was trying to avoid two steps to deploy:

 1 - mvn site-deploy on git repo to copy it to the CMS staging are
 2 - CMS deploy to publish it

 But I think that should not be a problem, Right?

 So what I'll do now, based on your PoC is to make the templates of
 the generated html to be close to deltaspike site style.

 Em 8/27/14, 17:10, John D. Ament escreveu:


 Rafael,

 This shouldn't be needed any longer.  Based on what I did, we can
 now do a mvn site-deploy to copy everything into the CMS staging
 area.  Once verified go into CMS and do a publish.

 John


 On Wed, Aug 27, 2014 at 3:57 PM, Rafael Benevides
 benevi...@redhat.com mailto:benevi...@redhat.com wrote:

 Hi all,

 This email is just to give a feedback about making CMS to
 work with Github and Asciidoc.

 Finally  I was able to understand enough how CMS works and
 probably I'm stopped where John Ament was.

 What I'm doing now is writing a GitUtil Perl Module that will
 be hosted at
http://svn.apache.org/repos/asf/deltaspike/site/trunk/lib/
 that will be responsible for cloning the documentation (on
 deltaspike git repo) and then another module will run the
 build (asciidoc to html) just for [git_root/documentation/].

 The idea is that the final documentation gets hosted at
 deltaspike.apache.org/documentation/
 http://deltaspike.apache.org/documentation/ (note the sub
 folder).

 Further steps: Prepare a template so asciidoc generated html
 uses the same style of deltaspike.apache.org
 http://deltaspike.apache.org.

 Well, the idea here is to make everyone aware about this and
 also say that if is there anybody if Perl knowledge, you're
 welcome to give some hints!

 Thanks


 --
 *Rafael Benevides | Senior Software Engineer*
 JBoss Developer
 M: +55-61-9269-6576 tel:%2B55-61-9269-6576

 Red Hat

 Better technology. Faster innovation. Powered by community
 collaboration.
 See how it works at www.redhat.com http://www.redhat.com/

 LinkedIn http://www.linkedin.com/company/3258288 Youtube
 https://www.youtube.com/redhatlatam











Re: Data Module - some issues in SE/Maven Tests

2014-09-01 Thread Romain Manni-Bucau
Hi

Archive url issue is due to the arquillian adapter (so no problem for data
module)

Can't the other one be fixed using @Typed?
Le 1 sept. 2014 21:41, John D. Ament john.d.am...@gmail.com a écrit :

 Hi All!

 I've hit a couple of issues with the Data Module and wanted to know if it
 was worth fixing.

 First, my sample app can be found at [1] (note you'll need JDK8 to run) and
 you can run the test JPATest to see the results, using

 mvn -Dtest=JPATest -Ddeltaspike.version=1.0.2

 First issue you'll note is that the following output (or something similar
 to it will be given):

 java.lang.IllegalArgumentException: URL does not exist:
 archive:se-examples.jar/META-INF/persistence.xml

 at

 org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)

 at

 org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)

 at

 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)

 at

 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)

 at

 org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)

 at

 org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:73)

 (full stack available at [2], test.log).  It seems like the
 RepositoryExtension is picking up on my persistence.xml and aggressively
 trying to parse them (at this point, I don't have any @Repository's defined
 in my app).  For some reason it cannot parse this URL but it does seem to
 pick up the persistence.xml from target/classes/META-INF so it does
 eventually parse it.  To work around this, I wrapped
 DescriptorReader.readAllFromClassPath's result.add with an exception check.
  I figure if it can't read the descriptor, no reason to make the whole app
 die.  What do you think?

 Second issue, after fixing this one, was that AbstractEntityRepository was
 being picked up as a @Repository and erroring out saying that there's no
 entity for it. This one I wasn't expecting.  To fix it, in
 RepsitoryComponents, I added an explicit check if it was the base class, if
 it was return null rather than exception and check for null in the add
 method.  This also fixed things and the tests started running fine.  This
 fix seems more hacky, and I'm wondering if I'm just doing something wrong
 to make this class be picked up.

 You can see the summary of changes in the gist's patch.txt.

 John


 [1]: https://github.com/johnament/restful-and-beyond-tut2184
 [2]: https://gist.github.com/johnament/d4a55ce7251062ee0b85