@author tags in our codebase
by Randall Hauch
I've recently read a suggestions for open source communities that the
author names are removed from the content. In the case of DNA's
codebase, that would mean removing the @author tags. I'm not sure
there was a lot of thought put into using author tags vs. not using
them, but I'd like to reconsider our policy.
What does everyone think about the @author tags? Please reply to all,
stating your opinion (or lack of one).
I'll start. I see a couple of advantages to getting rid of all
@author tags:
When there are no @author tags, then there is a far smaller notion of
ownership by the author(s). On one side of this, the author(s) may
not appreciate changes to "their" code, and on the other side, non-
authors may feel intimidated about working on code for which they are
not an author. IMO, we want to _discourage_ ownership and _encourage_
everyone to work in any area of the code they want.
When there are no @author tags, we don't need a policy that says when
you can add your name to a class/method as an author. I'm not even
sure what our policy is, but I think we're not being consistent (other
than when we create a new class/interface)
@author tags can be inaccurate. SVN has the true history of who
contributed exactly what code.
The only benefit I can think of is that the @author tag does help to
give some notion of who is the "expert" of the class, in case they
need to be consulted. However, I don't believe this is really much of
a reason, since it's far better to consult the SVN history and see who
actually modified the different parts of the code. In fact, the
annotated views in Fisheye even show on many of the lines the name of
the last person to change it. For example, see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
What does everyone think about the @author tags? This isn't an
official vote (we've never had one), but I would like to hear
everyone's thoughts, so please reply to all and let us know what you
think.
Best regards,
Randall
16 years, 11 months
- 3
- 5
Re: Proposal: new sandbox area for DNA
by Serge Emmanuel Pagop
Hi all,
I agree with that proposal with the sandbox area, then dna should be
release with the most stable subprojects and definition of stable can
only be define by the project leader depend on with features the
subproject has to at the least provide.
For me because of the youthfulness of DNA project, we can also release
all subproject, that provide a minimun upon functionalities, so that
we can win some contributors in the community. Of Course "a minimun
upon functionalities" has also to be defined.
Best regards,
Serge.
> Send dna-dev mailing list submissions to
> dna-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/dna-dev
> or, via email, send a message with subject or body 'help' to
> dna-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> dna-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dna-dev digest..."
>
>
> Today's Topics:
>
> 1. Proposal: new sandbox area for DNA (Randall Hauch)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 23 Nov 2008 11:47:08 -0600
> From: Randall Hauch <rhauch(a)redhat.com>
> Subject: [dna-dev] Proposal: new sandbox area for DNA
> To: JBoss DNA <dna-dev(a)lists.jboss.org>
> Message-ID: <00474E51-4FBF-4957-937B-B6B8AE4194CD(a)redhat.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I've been wondering recently how to distinguish the (Maven)
> subprojects under trunk that are ready for use vs. those that are
> still under development. In fact, it's not even only the source
> organization, as our release binaries have included all projects
> (regardless of their state). I've tried to note the status in the
> documentation, but I think that is insufficient and we need something
> that is more formal, obvious, and intuitive for users.
>
> The 0.3 release included several projects that were not really "ready
> for use":
> dna-sequencer-cnd
> dna-sequencer-esbMessage
> dna-sequencer-jbpm-jpdl
> dna-connector-svn
>
> And since the 0.3 release we have started (or will so be starting)
> several new subprojects:
> dna-connector-store-jpa
> dna-connector-jdbc-metadata (soon to be created)
>
> So, here's my proposal: we'd create in SVN a new "sandbox" directory
> under the "trunk" directory, and in this area is generally where
> subprojects would live until they are "mature enough" to move outside
> of the "sandbox". In some cases, "mature enough" means that they are
> indeed complete, while in other cases they may be far enough along and
> there's commitment to finish them before the next release. I'd
> anticipate that we'd be flexible on what "mature enough" means and
> decide on a case-by-case basis as a community when a sandbox project
> is "mature enough" on a case-by-case basis (although ultimately the
> project lead would have the final say). However, sandbox projects
> would be excluded from the binary release assembly (but maybe included
> in the source assembly?) and would not be mentioned in the Getting
> Started document, and all mentions in the Reference Guide would be
> moved to a new chapter covering the sandbox.
>
> Also, with this proposal, I'd think we would still keep all of the
> sandbox projects in our development environments (unless other wise
> requested by a project's developers). And these sandbox projects
> would still included in the Maven builds and Hudson CI jobs.
>
> Here's a strawman list of existing extensions that could be moved into
> the "sandbox", based purely upon my understanding of where these
> projects are and the plans to complete them by 0.4:
> dna-classloader-maven (complete, but to be of any use it really needs
> additional components, like perhaps a Maven or SVN connector)
> dna-sequencer-cnd
> dna-sequencer-esbMessage
> dna-sequencer-jbpm-jpdl
> dna-connector-jdbc-metadata (soon to be created)
> dna-sequencer-jdbc-metadata (actually, this is to be removed)
>
> These projects would stay in "trunk", since they are planned to be
> completed for 0.4:
> dna-connector-svn
> dna-connector-store-jpa
>
> Forgive me if my understanding of the state of these projects is
> wrong. If that's the case, please speak up and correct me.
>
> So, what do you think of this proposal? Please weigh in with your
> thoughts and opinions about the proposal and the suggested list of
> "sandbox" subprojects.
>
>
> Best regards,
>
> Randall
>
17 years
- 3
- 3
Proposal: new sandbox area for DNA
by Randall Hauch
I've been wondering recently how to distinguish the (Maven)
subprojects under trunk that are ready for use vs. those that are
still under development. In fact, it's not even only the source
organization, as our release binaries have included all projects
(regardless of their state). I've tried to note the status in the
documentation, but I think that is insufficient and we need something
that is more formal, obvious, and intuitive for users.
The 0.3 release included several projects that were not really "ready
for use":
dna-sequencer-cnd
dna-sequencer-esbMessage
dna-sequencer-jbpm-jpdl
dna-connector-svn
And since the 0.3 release we have started (or will so be starting)
several new subprojects:
dna-connector-store-jpa
dna-connector-jdbc-metadata (soon to be created)
So, here's my proposal: we'd create in SVN a new "sandbox" directory
under the "trunk" directory, and in this area is generally where
subprojects would live until they are "mature enough" to move outside
of the "sandbox". In some cases, "mature enough" means that they are
indeed complete, while in other cases they may be far enough along and
there's commitment to finish them before the next release. I'd
anticipate that we'd be flexible on what "mature enough" means and
decide on a case-by-case basis as a community when a sandbox project
is "mature enough" on a case-by-case basis (although ultimately the
project lead would have the final say). However, sandbox projects
would be excluded from the binary release assembly (but maybe included
in the source assembly?) and would not be mentioned in the Getting
Started document, and all mentions in the Reference Guide would be
moved to a new chapter covering the sandbox.
Also, with this proposal, I'd think we would still keep all of the
sandbox projects in our development environments (unless other wise
requested by a project's developers). And these sandbox projects
would still included in the Maven builds and Hudson CI jobs.
Here's a strawman list of existing extensions that could be moved into
the "sandbox", based purely upon my understanding of where these
projects are and the plans to complete them by 0.4:
dna-classloader-maven (complete, but to be of any use it really needs
additional components, like perhaps a Maven or SVN connector)
dna-sequencer-cnd
dna-sequencer-esbMessage
dna-sequencer-jbpm-jpdl
dna-connector-jdbc-metadata (soon to be created)
dna-sequencer-jdbc-metadata (actually, this is to be removed)
These projects would stay in "trunk", since they are planned to be
completed for 0.4:
dna-connector-svn
dna-connector-store-jpa
Forgive me if my understanding of the state of these projects is
wrong. If that's the case, please speak up and correct me.
So, what do you think of this proposal? Please weigh in with your
thoughts and opinions about the proposal and the suggested list of
"sandbox" subprojects.
Best regards,
Randall
17 years, 1 month
- 1
- 0
Re: JIRA and Wiki
by Sergey Litsenko
Hi All,
A number of interesting ideas appeared in recent dna-dev digest emails. While I'm not deleting my e-mails but I suppose I'm not the only one who found it difficult to manage our design minutes and proposals in e-mails.
May I suggest something (as it also has being pointed out by Randall in our discussions about JDBC graphs)?
It would be nice to see summary of your design proposals/ideas as a JIRA tickets for future releases OR as comments to existing tickets (where related/existed) PLUS links to your WIKI with details - so your ideas don't get lost in e-mail threads. And we can vote on these tickets and understand more about priorities and future plans for components. Your detailed proposals and SDD can be managed by JBoss Wiki. JIRA is a good place to record/track progress of bugs and new feature requests, and Wiki is a good place for our collaboration and ideas.
What do you think?
Best regards,
Sergiy
________________________________
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
To: dna-dev(a)lists.jboss.org
Sent: Friday, 21 November, 2008 4:00:06 AM
Subject: dna-dev Digest, Vol 8, Issue 14
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. Re: SOA/Enterprise project using DNA (Randall Hauch)
2. Re: SOA/Enterprise project using DNA (Stefano Maestri)
----------------------------------------------------------------------
Message: 1
Date: Thu, 20 Nov 2008 01:10:28 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: Re: [dna-dev] SOA/Enterprise project using DNA
To: Michael Neale <michael.neale(a)gmail.com>, JBoss DNA
<dna-dev(a)lists.jboss.org>
Message-ID: <B8CF0E86-E60A-4A1B-BBC6-4EAB6BE9F09B(a)redhat.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I'm also working on a connector that stores the graph in a DB using
Hibernate. It's not complete, so I don't have any numbers yet. But
it's coming along nicely, and I did try to solve some of the problems
with how JR persistence works.
On Nov 19, 2008, at 11:50 PM, Michael Neale wrote:
> that sounds ideal. I know myself and others are not entirely
> comfortable with jackrabbit - particularly the way it stores thing in
> RDBMS (although if we are using jboss cache and its persistence - I am
> not sure if we will do much better then blob storage??).
>
> On Thu, Nov 20, 2008 at 3:05 PM, Randall Hauch <rhauch(a)redhat.com>
> wrote:
>> Actually, I'm hoping that we can support binary property values
>> (which is
>> actually where JCR stores file content, but you know that :-) in
>> memory
>> mapped (direct) buffers. That way, they don't take up any memory.
>> Plus, by
>> using federation and a file system connector, we could store these
>> large
>> files on the file system and just handle the "references" as property
>> values, opening a stream to the underlying only when required. Of
>> course,
>> you're app would have to pay the price for streaming gigabytes of
>> information. :-)
>>
>> How does this sound?
>>
>> Best regards,
>>
>> Randall
>>
>> On Nov 19, 2008, at 9:09 PM, Michael Neale wrote:
>>
>>> For our SOA repository, and rules - its possible we are looking at
>>> large single artifacts, as well as many small ones (which kind of
>>> stretch most JCR implementations). One idea floated is to (possibly)
>>> one day store entire machine images (OMG !!!) in the repository
>>> (obviously in memory will not work in that case !). But its hard to
>>> nail things down isn't it...
>>>
>>> On Thu, Nov 20, 2008 at 7:21 AM, Randall Hauch <rhauch(a)redhat.com>
>>> wrote:
>>>>
>>>> Stefano, this sounds great! Personally, I really like to hear
>>>> these
>>>> kinds
>>>> of use cases and scenarios. It's always important to know
>>>> whether we're
>>>> working on the "right" set of features. So keep these use cases
>>>> coming!
>>>>
>>>> And, please feel free to suggest or discuss features that might be
>>>> useful,
>>>> too. For example, do you think JCR versioning will be an
>>>> important part
>>>> of
>>>> your approach, or will you implement your own approach to managing
>>>> history
>>>> by designing the hierarchy to handle it? Also, do you have an
>>>> idea about
>>>> how much information the repository will store (perhaps broken
>>>> down by %
>>>> in
>>>> uploaded files, and about how big those files will each be).
>>>>
>>>> Best regards,
>>>>
>>>> Randall
>>>>
>>>> On Nov 18, 2008, at 3:34 PM, Stefano Maestri wrote:
>>>>
>>>>> Hi all,
>>>>> as said in a previous post I'm going to start a SOA/Enterprise
>>>>> project
>>>>> using DNA for an important part of the project.
>>>>> I'm finishing the design of the whole application, but I can
>>>>> describe
>>>>> here the main idea and how DNA will be related.
>>>>>
>>>>> In a nutshell we are SOAfing a complex system of a customer
>>>>> (J2EE+.NET+Oracle mainly, with external partner and provider
>>>>> with SOAP
>>>>> service and/or custom legacy services).
>>>>> The system use a lot of data stored in various resources (mainly
>>>>> relationl DB, but also someone provided from partner services).
>>>>> Some
>>>>> code (in all languages) apply business rules to this data and
>>>>> transform
>>>>> it in a some enrich information (information=data+Business rules).
>>>>> Aggregating this data we build a final report to client that is
>>>>> the
>>>>> final product.
>>>>> As said we are moving to SOA and we are identifying services and
>>>>> aggregation of them. The area where DNA could be very useful is
>>>>> solving
>>>>> the problem of keeping track of information during time.
>>>>> IOW we are asked to be able to provide not only current
>>>>> information, but
>>>>> also information related to a particular moment (remember
>>>>> information
>>>>> for us= data + business rules).
>>>>> The system (or better a lot of service provider we are
>>>>> considering part
>>>>> of the system) haven't ability to keep data or bsiness rules
>>>>> history, so
>>>>> we have to store in some other places answer to be able to
>>>>> retrive them
>>>>> in future.
>>>>> Here DNA could help us: the basic idea is to use JBossESB as
>>>>> integration
>>>>> layer where a MessageStore could store messages into DNA where
>>>>> we can
>>>>> apply different sequencers to extract information and organize
>>>>> it for
>>>>> our different future purpose.
>>>>>
>>>>> ok, a bit confused, but it's late night and I'm tired and
>>>>> moreover the
>>>>> project is on its start up.
>>>>>
>>>>> I'll try to explain better details regarding DNA very soon, as
>>>>> soon as I
>>>>> finished my design.
>>>>>
>>>>> bye
>>>>> S.
>>>>> _______________________________________________
>>>>> dna-dev mailing list
>>>>> dna-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>>
>>>> _______________________________________________
>>>> dna-dev mailing list
>>>> dna-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/dna-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Michael D Neale
>>> home: www.michaelneale.net
>>> blog: michaelneale.blogspot.com
>>
>>
>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
------------------------------
Message: 2
Date: Thu, 20 Nov 2008 15:58:03 +0100
From: Stefano Maestri <stefano.maestri(a)javalinux.it>
Subject: Re: [dna-dev] SOA/Enterprise project using DNA
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <49257AFB.7050207(a)javalinux.it>
Content-Type: text/plain; charset=ISO-8859-1
Randall Hauch wrote on 19/11/08 21:21:
>
> And, please feel free to suggest or discuss features that might be
> useful, too.
The feature I'd like to see in a next future, not necessary for 0.4 of
course, is write connectors for graph api on DB and maybe on a
distributed storage (like hadoop). We will have a lot of data here, see
below.
> For example, do you think JCR versioning will be an important part of
> your approach, or will you implement your own approach to managing
> history by designing the hierarchy to handle it?
No it isn't for our impl. What we are going to do is to keep a snapshot
of service responses linked to a particular user request. We keep of
course accounting of user requests and we will use the primary key of
accounting system to keep versioning. (I hope I've been sufficient clear
in my explanation, if not just shout :) )
What we could need, not in the fisrt step of the project anyway, is
analyzer to extract different views of data already saved in JCR with a
particular structure. JCR is good because infos are already organized in
the way we will read them, but I'm not sure we will get perfect fit of
our needs at fist shot. So I immagine analyzers a way to re-organize JCR
in different manner (better).
> Also, do you have an idea about how much information the repository
> will store (perhaps broken down by % in uploaded files, and about how
> big those files will each be).
It is incremental increasing of course. Not a precise idea since we are
reviewing all the system to go to service. But we expect 1 terabyte in
18/24 months based on the experience of data we are storing on a DB. We
have a DB of pure data of 5 TB and we have an increasing of about 0.7
TB/year. We are not moving all data on JCR, but service data are more
expensive than pure datas....well it isn't a precise prevision...I'll be
more precise later in the project.
Bye
S.
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 8, Issue 14
**************************************
Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail
17 years, 1 month
- 3
- 2
SOA/Enterprise project using DNA
by Stefano Maestri
Hi all,
as said in a previous post I'm going to start a SOA/Enterprise project
using DNA for an important part of the project.
I'm finishing the design of the whole application, but I can describe
here the main idea and how DNA will be related.
In a nutshell we are SOAfing a complex system of a customer
(J2EE+.NET+Oracle mainly, with external partner and provider with SOAP
service and/or custom legacy services).
The system use a lot of data stored in various resources (mainly
relationl DB, but also someone provided from partner services). Some
code (in all languages) apply business rules to this data and transform
it in a some enrich information (information=data+Business rules).
Aggregating this data we build a final report to client that is the
final product.
As said we are moving to SOA and we are identifying services and
aggregation of them. The area where DNA could be very useful is solving
the problem of keeping track of information during time.
IOW we are asked to be able to provide not only current information, but
also information related to a particular moment (remember information
for us= data + business rules).
The system (or better a lot of service provider we are considering part
of the system) haven't ability to keep data or bsiness rules history, so
we have to store in some other places answer to be able to retrive them
in future.
Here DNA could help us: the basic idea is to use JBossESB as integration
layer where a MessageStore could store messages into DNA where we can
apply different sequencers to extract information and organize it for
our different future purpose.
ok, a bit confused, but it's late night and I'm tired and moreover the
project is on its start up.
I'll try to explain better details regarding DNA very soon, as soon as I
finished my design.
bye
S.
17 years, 1 month
- 3
- 6
JBoss DNA 0.4 planning
by Randall Hauch
Now that 0.3 is almost out the door, I'd like to start discussing the
goals for the next release.
I'd love to see the JCR implementation take more shape. Right now
it's read-only, so getting that much farther along would be
outstanding. Anybody interested? I think we could easily put several
people to work here. The graph API is pretty good, and should make
implementing JCR relatively straightforward. Any interest, Michael
Trezzi and Alexandre and Serge?
We need to add events to the connector framework. That should be
pretty straightforward. Also versioning, which will require a bit
more work. Plus, there are a couple of connectors that we may want to
start working on. This is something I'd be happy to continue with.
Serge P. also has expressed interest in working on some connectors (in
fact his SVN connector is coming along great!).
The CND sequencer could use some love and attention. Dan was stuck in
some ANLTR hell, and got pulled off onto a different project. Since
it uses ANTLR, maybe you might be interested in it, Alexandre?
We also have a need to start working on a REST/WebDAV layer that
allows other client apps to access a DNA repository. There's a couple
of things we can do, including looking at Apache Sling, or using
RESTeasy for a more simple implementation, or something else. Sergiy
and John both expressed interest in this.
Anything else?
We can either tackle several things at once and move them all
incrementally, or we can do more in just a few areas. Ideally, we're
looking at a 4-5 week cycle (finishing before the year-end holidays.)
A lot will depend on how much effort people might be able to dedicate
to the project.
Please respond with your thoughts and comments!
Best regards,
Randall
17 years, 1 month
- 3
- 8
Re: Re: @author tags in our codebase
by Sergey Litsenko
>Re: @author tags in our codebase
As long as author's contribution is acknowledged in some sort (icense information at the beginnig of any file, JIRA, Fisheye/SVN log, etc) it doesn't really matter having or not having @author tags.
IMO, it's no shame to have it as part of header, but its optional. Some people like edge cases and just making excuses of not contributing they knowledge ;)
Best regards,
Sergiy
________________________________
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
To: dna-dev(a)lists.jboss.org
Sent: Wednesday, 19 November, 2008 10:03:47 AM
Subject: dna-dev Digest, Vol 8, Issue 11
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. Re: @author tags in our codebase (Stefano Maestri)
2. Re: JBoss DNA 0.4 planning (Stefano Maestri)
3. Re: @author tags in our codebase (Randall Hauch)
4. SOA/Enterprise project using DNA (Stefano Maestri)
5. Re: Re: JBoss DNA 0.4 planning (Sergey Litsenko)
----------------------------------------------------------------------
Message: 1
Date: Tue, 18 Nov 2008 21:52:06 +0100
From: Stefano Maestri <stefano.maestri(a)javalinux.it>
Subject: Re: [dna-dev] @author tags in our codebase
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <49232AF6.6060000(a)javalinux.it>
Content-Type: text/plain; charset=ISO-8859-1
Randall Hauch wrote on 17/11/08 22:17:
> I've recently read a suggestions for open source communities that the
> author names are removed from the content. In the case of DNA's
> codebase, that would mean removing the @author tags.
May I ask where?
>
> tags:
>
> 1. When there are no @author tags, then there is a far smaller
> notion of ownership by the author(s). On one side of this, the
> author(s) may not appreciate changes to "their" code, and on the
> other side, non-authors may feel intimidated about working on
> code for which they are not an author. IMO, we want to
> _discourage_ ownership and _encourage_ everyone to work in any
> area of the code they want.
>
+1...but is really @author tag intimating someone, or giving ownership
to some other? Quiet frankly not for me.
Anyway I agree on the _discurage_ownership and _encourage_everyone to
work in any area, so if it can help, remove @author tag.
> 1. @author tags can be inaccurate. SVN has the true history of who
> contributed exactly what code.
>
+1
>
> The only benefit I can think of is that the @author tag does help to
> give some notion of who is the "expert" of the class, in case they
> need to be consulted. However, I don't believe this is really much of
> a reason, since it's far better to consult the SVN history and see who
> actually modified the different parts of the code. In fact, the
> annotated views in Fisheye even show on many of the lines the name of
> the last person to change it. For example,
> see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
>
abosolutely better to use fisheye...if fine people of JBoss.org would
also mind to upgrade it to a more recent version it would be even
better. Also Jira integration may help a lot.
I would just add that if we decide to remove the tag we have to change
also the license information at the beginnig of any file which say:
/* 2
<http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...>
* JBoss, Home of Professional Open Source. 3
<http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...>
* Copyright 2008, Red Hat Middleware LLC, and individual contributors 4
<http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...>
* as indicated by the @author tags. See the copyright.txt file in the 5
<http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...>
* distribution for a full listing of individual contributors.
bye
S.
------------------------------
Message: 2
Date: Tue, 18 Nov 2008 21:58:21 +0100
From: Stefano Maestri <stefano.maestri(a)javalinux.it>
Subject: Re: [dna-dev] JBoss DNA 0.4 planning
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <49232C6D.2020104(a)javalinux.it>
Content-Type: text/plain; charset=ISO-8859-1
Randall Hauch wrote on 17/11/08 21:20:
> On Nov 17, 2008, at 2:17 PM, Stefano Maestri wrote:
>> Randall Hauch wrote on 04/11/08 19:37:
>>
> Actually, this "writing" that we should support in 0.4 was referring
> to the parts of the JCR implementation that change the graph. Right
> now, the JCR implementation only has implementations for the "read"
> methods. Architecturally, the JCR implementation uses our new Graph
> API introduced in 0.3. The idea is that the JCR implementation works
> with everything as graph content managed by a connector. Even the
> NodeTypeManager would be implemented on top of the Graph API. Events
> may also be addressed in 0.4, but versioning, search and query would
> likely be handled in 0.5. (Actually, if that's true, then 0.5 might
> actually be 1.0).
ok, about events query and so on. I've understood they wouldn't go in 0.4
>
> Now, you asked about plans for storing graph content in a relational
> DB or other systems (e.g., Hadoop). Just to be clear, the Graph API
> already supports reading and writing, and we'll be adding events in
> 0.4. The only 0.3 connector that supports persisting content is the
> JBoss Cache connector (relying upon JBoss Cache's ability to persist
> the cache content in a relational database or file system). But I'm
> already working on a new connector that stores graphs in a relational
> database using JPA (using Hibernate for the implementation).
> Hopefully that will be available soon.
Yep I know about Graph API. I just skipped some step in my
question...I've been tired, sorry.
>
> Yes, I agree. The question is if multiple people are working on the
> JCR implementation, do they collaborate on one feature at a time, or
> do they each work on their own part of the JCR implementation? I
> don't have a preference, but would like those wanting to work on the
> JCR implementation to decide.
Depends on how much time each one can put in this implementation.
>From my side I think I can promise more or less a part time
collaboration (let me say 4 hours a day). Maybe some one of my men can
lend a hand too, but I'm not sure at the moment, it depends on how are
project will go.
>
>> I'll post very soon what my daytime project is and how it's related on
>> DNA, since I think it could be of some interest for the whole community
>> being one of the first enterprise project that would use DNA quiet
>> extensively.
>
> Wonderful! Can't wait to see it.
Ok, on the wire ;)
bye
S.
------------------------------
Message: 3
Date: Tue, 18 Nov 2008 15:33:18 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: Re: [dna-dev] @author tags in our codebase
To: Stefano Maestri <stefano.maestri(a)javalinux.it>, JBoss DNA
<dna-dev(a)lists.jboss.org>
Message-ID: <C2180265-75AE-470B-AA3D-3A27C2B93777(a)redhat.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On Nov 18, 2008, at 2:52 PM, Stefano Maestri wrote:
>
> Randall Hauch wrote on 17/11/08 22:17:
>> I've recently read a suggestions for open source communities that the
>> author names are removed from the content. In the case of DNA's
>> codebase, that would mean removing the @author tags.
> May I ask where?
I knew someone was going to ask. :-) I had to go back and look, but
here are a few:
http://video.google.com/videoplay?docid=-4216011961522818645&ei=8o0YSbiFO...
http://docs.ofbiz.org/display/OFBADMIN/Coding+Conventions
http://subversion.tigris.org/hacking.html#other-conventions
http://blogs.sun.com/ahe/entry/author_tags
>
>>
>> tags:
>>
>> 1. When there are no @author tags, then there is a far smaller
>> notion of ownership by the author(s). On one side of this, the
>> author(s) may not appreciate changes to "their" code, and on the
>> other side, non-authors may feel intimidated about working on
>> code for which they are not an author. IMO, we want to
>> _discourage_ ownership and _encourage_ everyone to work in any
>> area of the code they want.
>>
> +1...but is really @author tag intimating someone, or giving ownership
> to some other? Quiet frankly not for me.
I hope it doesn't discourage people from contributing and diving in
wherever they want. BTW, it's quite possible that no matter what our
policy, some people may not like it. For example, if we were to adopt
a policy of NOT including @author tags, some people may refuse to join
the community because they see the @author tag as proof they worked on
it. It takes all kinds of people. :-)
>
> Anyway I agree on the _discurage_ownership and _encourage_everyone to
> work in any area, so if it can help, remove @author tag.
>
>> 1. @author tags can be inaccurate. SVN has the true history of who
>> contributed exactly what code.
>>
> +1
IMO, this is perhaps the biggest justifiable reason. Its rubbish if
its not up-to-date, so it seems far better to not have @author tags.
>
>>
>> The only benefit I can think of is that the @author tag does help to
>> give some notion of who is the "expert" of the class, in case they
>> need to be consulted. However, I don't believe this is really much
>> of
>> a reason, since it's far better to consult the SVN history and see
>> who
>> actually modified the different parts of the code. In fact, the
>> annotated views in Fisheye even show on many of the lines the name of
>> the last person to change it. For example,
>> see http://fisheye.jboss.org/browse/DNA/trunk/dna-common/src/main/java/org/jb...
>>
> abosolutely better to use fisheye...if fine people of JBoss.org would
> also mind to upgrade it to a more recent version it would be even
> better. Also Jira integration may help a lot.
>
> I would just add that if we decide to remove the tag we have to change
> also the license information at the beginnig of any file which say:
> /* 2
> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
> * JBoss, Home of Professional Open Source. 3
> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
> * Copyright 2008, Red Hat Middleware LLC, and individual
> contributors 4
> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
> * as indicated by the @author tags. See the copyright.txt file in
> the 5
> <http://fisheye.jboss.org/browse/DNA/trunk/dna-graph/src/main/java/org/jbo...
> >
> * distribution for a full listing of individual contributors.
>
Yes, we'd have to update the headers.
Best regards,
Randall
------------------------------
Message: 4
Date: Tue, 18 Nov 2008 22:34:43 +0100
From: Stefano Maestri <stefano.maestri(a)javalinux.it>
Subject: [dna-dev] SOA/Enterprise project using DNA
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <492334F3.8050507(a)javalinux.it>
Content-Type: text/plain; charset=ISO-8859-15
Hi all,
as said in a previous post I'm going to start a SOA/Enterprise project
using DNA for an important part of the project.
I'm finishing the design of the whole application, but I can describe
here the main idea and how DNA will be related.
In a nutshell we are SOAfing a complex system of a customer
(J2EE+.NET+Oracle mainly, with external partner and provider with SOAP
service and/or custom legacy services).
The system use a lot of data stored in various resources (mainly
relationl DB, but also someone provided from partner services). Some
code (in all languages) apply business rules to this data and transform
it in a some enrich information (information=data+Business rules).
Aggregating this data we build a final report to client that is the
final product.
As said we are moving to SOA and we are identifying services and
aggregation of them. The area where DNA could be very useful is solving
the problem of keeping track of information during time.
IOW we are asked to be able to provide not only current information, but
also information related to a particular moment (remember information
for us= data + business rules).
The system (or better a lot of service provider we are considering part
of the system) haven't ability to keep data or bsiness rules history, so
we have to store in some other places answer to be able to retrive them
in future.
Here DNA could help us: the basic idea is to use JBossESB as integration
layer where a MessageStore could store messages into DNA where we can
apply different sequencers to extract information and organize it for
our different future purpose.
ok, a bit confused, but it's late night and I'm tired and moreover the
project is on its start up.
I'll try to explain better details regarding DNA very soon, as soon as I
finished my design.
bye
S.
------------------------------
Message: 5
Date: Tue, 18 Nov 2008 15:03:39 -0800 (PST)
From: Sergey Litsenko <litsenko_sergey(a)yahoo.com>
Subject: Re: [dna-dev] Re: JBoss DNA 0.4 planning
To: Randall Hauch <rhauch(a)redhat.com>, JBoss DNA
<dna-dev(a)lists.jboss.org>
Message-ID: <388296.99595.qm(a)web50506.mail.re2.yahoo.com>
Content-Type: text/plain; charset="utf-8"
>FLEX can be driven entirely
from data. Could Seam and Rich Faces be
used this way?
Sure. Did you have any chance to look at https://www.jboss.org/community/docs/DOC-12952 (especially RichFaces live demo links and RichFaces UI components - http://www.jboss.org/file-access/default/members/jbossrichfaces/freezone/... )?
Seam + JSF API + Facelets (XHTML templating)+ RichFaces (JSF
impl) are very flexible, have extension points and can implement majority of
RIA use cases (including an integration with plenty of other frameworks that
I’ve mentioned on the wiki page).
Seam/JSF/RichFaces integrated with other RIA frameworks like JQuery - http://jquery.com. Exadel proved that it is possible to integrate Flex and JavaFX with JBoss Seam (Exadel Flamingo and Exadel Fiji) - this addresses your concerns about "allowing graphical navigation".
However some “glue” code might be needed
depending of specific use case(s) – or we can make it generic.
In fact, Seam/JSF/RichFaces frameworks are very similar to Flex by
functionality but RichFaces/JSF relying on more generic, widely sources like
(X)HTML, JS, AJAX,
CSS. For example, both frameworks using
view described in XML; data binding in Flex (http://www.adobe.com/devnet/flex/quickstart/using_data_binding/)
is almost identical to JSF. For example, an input text UI control described as following:
FLEX: <mx:Text text="{myData.value}"/>
Pure JSF: <h:inputText value="#{myData.value}"/>
RichFaces: <rich:inplaceInput value="#{myData.value}"/>
Plus we can combine Flex + JSF too if needed.
IMO, what we should do first – regardless of preferred UI
choice - is that we would need to define
few critical/major use cases in
details in terms of pure
requirements (e.g. using language not specific to view frameworks) and
generic UI controls. And then see how it fits onto features of available
frameworks. This would help to understand what is really needed and jumpstart
on development of web app infrastructure.
>What if we put the REST service
on top of the Graph API (new to 0.3), which operates on top of a connector?
I agree that we need to consider both approaches side by
side and they impact on REST service implementation, and agree that both
mapping types might be twin brothers. So why don't we have core semi abstract class(es) that handles REST requiests based of http://jcp.org/en/jsr/detail?id=311 annotations and JBoss RestEasy implementation. And then two direct implementations based on Graph API (preffered?) and on JNDI/JCR API.
Basic question #1 to
answer: is REST service shall be considered an external component of
JBoss DNA that threat it as another JCR repository (black box), or is it
integrated part of DNA with some knowledge of internal processing/model?
BTW, same question is valid for other services (reporting,
analysis, etc), Web UI application.
Basic question #2 to
answer: shall we consider using Graph API for REST service, where we’ll
stop? In other words, do we need to use JCR API at all for components? What the boundaries between internal engine’s
code, and services.
IMO, we could use Graph API if it covers all traversal
access provided by JCR API + Query API (provided by JCR)? IMO, this bit is as much as important as federated tree of
nodes + traversal. It helps client to quickly find an important metadata in a
same way like Google does for internet search.
The clear advantage of using Graph API is that it can
provide some functionality behind the JCR API coverage.
On the other hand, considering that Graph API is the “core engine”
of JCR implementation, I doubt that using JCR API on top of Graph API will have
any visible impact on a performance (since JCR layer is extra thin and just
converts JCR call to Graph API call(s)).
I like an idea using Graph API but worrying about question
#2.
________________________________
From: Randall Hauch <rhauch(a)redhat.com>
To: Sergey Litsenko <litsenko_sergey(a)yahoo.com>; JBoss DNA <dna-dev(a)lists.jboss.org>
Sent: Monday, 17 November, 2008 4:24:48 AM
Subject: Re: [dna-dev] Re: JBoss DNA 0.4 planning
On Nov 16, 2008, at 4:25 AM, Sergey Litsenko wrote:
Regarding JDBC metadata.
...
1) I'll review new chapter "how to write custom connectors"and use the dna-connector-svn as a reference to implement the dna-connector-jdbc in extensions. It will accept two configuration styles to specify JDBC configuration - javax.sql.DataSource and more generic java.sql.Driver (connection URL, username/password, etc).
Maybe this would help or give you some ideas: this weekend I've created a prototype connector that uses Hibernate for persistent storage. (Not quite ready for committing to SVN, but should be this week). The RepositorySource implementation just has JavaBean properties for the regular connection properties for Driver-based connection, and another JavaBean property for the JNDI name of the DataSource. The RepositorySource has a transient Hibernate Ejb3Configuration, which it creates lazily (and stores as a transient attribute) before creating a RepositoryConnection. The Ejb3Configuration is created programmatically, so the Driver properties are set as properties, but the DataSource has to be set as a reference. (Yeah, the JNDI name could be set as a Ejb3Configuration property, but in order to support the XAResource, I need to get the DataSource object in the RepositorySource, which holds onto it via a transient attribute. This works with Hibernate,
since the config also has a setDataSource(DataSource) method. Oh, and to make testing easier (by eliminating requirement for JNDI), I also added a package-level setter for a DataSource object, which sets the transient attribute value. Let me know if you want to see code.
2) create dna-sequencer-jdbc-metadata subproject in extensions that will implement an interface similar to org.jboss.dna.graph.sequencers.StreamSequencer except for the “stream” input parameter because it is irrelevant for JDBC based conversations:
package org.jboss.dna.graph.sequencers;
public interface JdbcSequencer {
void sequence(java.sql.Connection jdbcConnection,
SequencerOutput output,
SequencerContext context);
}
The main purpose – is to make it generic enough to allow implementing different JDBC sequencers.
How it sounds?
Basically, what I need to do is to port my DatabaseMetadata Extractor (I did it few years ago, and tested against Oracle9i, MS SQL Server 2005, and MySQL) into org.jboss.dna space. The extractor as whole package is a bit too heavy to just simply copy it – it is relying on several Apache\Jacarta libraries (notably on Jacarta commons Chain (Chain of Responsibility" pattern) + generates JDBC drivers comparison reports in XML and HTML. So, I’m trying to refactor it in the same time.
Okay, I think I see what you're trying to do. Very interesting idea. This would all be in the connector, then? And the connector would essentially cache the metadata graph extracted from the database metadata, so it could respond to the different ReadNodeRequest (or other requests) coming into the connector? (If I don't have this right, please let me know.) Also, if you're refactoring the extractor, would it be possible for the extractor to be used directly the connector to obtain only part of the metadata?
BTW, the musings I've had in the past about this connector is that it might use Hibernate (to automatically get support for the many database management systems that Hibernate already supports; see http://www.hibernate.org/80.html). Hibernate Tool's DatabaseMetadata class works on top of the many dialects that Hibernate has (http://www.hibernate.org/hib_docs/v3/api/org/hibernate/tool/hbm2ddl/Datab...). Again, not sure if this would even work or provide everything we'd want. For example, it may not provide much (if any) of the database-specific metadata.
Regarding REST mapping. My intention was to just describe “prior art” for reference purposes only – let others to they work - while it sounds like Jerome K. Jerome’s famous quote about his addiction to work ;) - we may save more time on analysis of possible REST mapping strategies.
My point is simple (and btw, it didn’t changed for years) – “program to interfaces”, likely standards based and setup transparent links (inject, configure, etc) to open source software implementations (preferably) of those interfaces where appropriate and possible.
I’m completely agree with your comments on that, and even more – inspired by your feeling towards choosing right balance between writing own code and reusing available libraries and frameworks I decided to spend some time analysing possible choices and wrote a wiki page about prospective ways to integrate/implement various JBoss DNA components in the future. Basically its small review of technologies available in OSS community (especially in JBOSS community) that might be related to JBoss DNA concept and might be reused in its implementation – have a look at it here https://www.jboss.org/community/docs/DOC-12952 – your comments are greatly appreciated. The main purpose of that review was to make the DNA implementation technology(s) / framework(s) choices broader and to address time to market requirement (while I love those frameworks and JEE in particular - I don’t want to push it too hard). The bottom line is that one of the main JBoss
DNA/JCR and JBoss DNA/Web purposes shall be to simplify metadata management things, not to complicate them – from client prospective. Plus (I guess) serve as JBoss technology stack show case (to some reasonable degree).
So, basically we will stick with JCR API for traversal, search, update nodes and map it onto URL, right?
The beauty of JCR API is that we don’t need to wait till our JCR implementation will be ready to integrate with other frameworks or services. As long as all components will rely strictly on JCR API interfaces and access it through standard way (e.g. JNDI lookup, dependency injection, etc) – we can easily use JackRabbit embedded in a meantime, and then substitute it with our JCR implementation when it became ready. We would need to address performance limitations of JackRabbit in our implementation of JCR API – in order to make it better (since it mean to be enterprise wide repository – e.g. thousands of nodes, subnodes, properties).
Yes, that is an entirely valid, and maybe preferred approach. Yes, we could start working on the REST service today. But a disadvantage is that we couldn't use the REST API on top of DNA repositories until our JCR API was finished (or at least those parts that the REST service would use).
Also, it doesn't seem like the REST service would use much of the JCR API. (Yes, this may make it easier to get our JCR implementation complete enough to put the REST service on top of DNA repositories.) But are we making it more complicated than it needs to be? What if we put the REST service on top of the Graph API (new to 0.3), which operates on top of a connector. This is essentially all that our JCR implementation is doing. The Graph API can read and write today, and it basically just consists of nodes with properties and children. And my intuition (nothing more than that!) is that the REST mapping to JCR would also map similarly/identically to the Graph API. The benefit is that this would be more efficient, since the extra JCR layer is eliminated.
I'm not sure what my preference would be. Both have advantages and disadvantages. But maybe we could consider both before we decide. Anyone have thoughts here?
I have the same opinion like you that RESTful service in not the equal to web app UI. We need separate JIRA ticket(s) for Web UI app, each panned/proposed WS (e.g. REST-based API for remote access and usage).
Also, we would need to clarify deployment scenarios of JBoss DNA stack in detail (like JackRabbit’s team did) – also highlighted on my wiki page.
Regarding Web application UI. I’m not against Flex as one of possible UI rendering but I’m just not sold on the fact that Flex is the first or preferable choice for DNA UI. Reasons explained in more detail on the same wiki page – but basically it is all about infrastructure and technology/feature enablers that btw already part of JBoss stack. For instance, thin and rich JSF framework like RichFaces that nicely integrates with JBoss Seam as a web infrastructural component might implement all required UI functionality. It is easy to use, understand how it works (both projects have comprehensive documentation) + my past experience with both frameworks might help in setting up quickly web infrastructure for JBoss DNA web.
I would agree that it's very important for other technologies (like Seam, RichFaces, GWT, even plain-old JSPs) to use JBoss DNA, because people writing web applications should be able to use JBoss DNA. However, I believe that we also need to provide an out-of-the-box ready-to-use metadata management repository web application, and that this will likely need to be offer rich interaction model (maybe even allowing graphical navigation). But perhaps the most critical need is for the application to over ways of customizing and extending how it views information, by not changing the application but by adding/changing data. This is content-driven, and not many frameworks make this possible. For example, GWT does not, since everything must be coded in Java and then compiled into the application. FLEX can be driven entirely from data. Could Seam and Rich Faces be used this way?
Best regards,
Sergiy
________________________________
From: Randall Hauch <rhauch(a)redhat.com>
To: Sergey Litsenko <litsenko_sergey(a)yahoo.com>; JBoss DNA <dna-dev(a)lists.jboss.org>
Sent: Tuesday, 11 November, 2008 2:57:38 AM
Subject: Re: [dna-dev] Re: JBoss DNA 0.4 planning
Excellent! Can't wait to see what you have. You're right that we could code to JSR 311 and use any valid implementation, but I have no problem relying upon RESTeasy, since we could leverage new features (e.g., http://bill.burkecentral.com/2008/11/10/jax-rs-atom-support-with-resteasy/), and since the RESTful service would certainly be packaged to run in a servlet container and thus shouldn't have any problems with clashes in dependencies. Plus, RESTeasy is another JBoss technology.
I'm wondering if you meant to say a JDBC Metadata "connector" (rather than "sequencer"). If you did mean "sequencer", I'd be interested in hearing about how that might work (what might be sequenced so the sequencer knows how to establish the connection and retrieve the metadata).
Now, regarding a REST mapping. I've looked at Sling (which has other features besides just a REST service), and based upon the documentation (which may very well be out of date), the client specifies the content type in the URL - that's not very appealing. I would much rather see standard content negotiation via the standard accept header. Now, the other two examples don't always look very RESTful (or at least "resource oriented"). For example, Alfresco's REST API's login method (http://wiki.alfresco.com/wiki/Repository_RESTful_API_Reference#Login) uses GET even though it's not idempotent. POST would seem to be better here. I would love to see a more detailed discussion on the REST mapping. Perhaps you could start off with what you've used in your prototype?
Another important topic is this: will we want to build a content-driven application framework or will we want to use Sling or Alfresco's WebScripts (or other)? Some advantages of reusing an existing system are:
* more functionality out of the box (i.e., we're not 1+ years behind)
* reuse existing technology
* leveraging existing community and possibly expand DNA community via participation in the other community
There are probably others, too. Some disadvantages are:
* must choose a technology
* must live with their interface and design
* little or no value-add over the existing technology
* our JCR support must be close-to-complete before we can do this
I'm a bit conflicted: I think we could do better, but just because we can doesn't mean we should. There's something to be said about focusing on what makes DNA unique and advantageous (primarily federation and sequencing), and just using Sling or Alfresco to build out some great useable applications. In fact, I think that a really usable and really useful content-driven rich internet application (perhaps using Flex) is another potential focus area for DNA.
So, as long as as have a correct and complete (enough) JCR implementation, then we (or anyone else) should be able to use DNA in combination with Sling and/or Alfresco. We may even win over the Alfresco community, if DNA's repository implementation is better than Jackrabbit. (Jackrabbit does a lot of things well, but there are some things it doesn't do well. All we need to do is be better at how Alfresco uses JCR.)
Now, having said that, I think that a RESTful service is not the same as a content-driven application framework. I think DNA should offer a lightweight, full-functioning RESTful service that doesn't depend on the larger content-driven applications. After all, I think many embedded use cases will simply want a deployable RESTful service so that client apps can work with a remote (federated) repository. And I think we can achieve this with very little code using RESTeasy (or maybe even other JSR-311 implementations). So we definitely need to do this.
Best regards,
Randall
On Nov 10, 2008, at 6:04 AM, Sergey Litsenko wrote:
Hi All,
I've already started working on (not yet in SVN - will wait till 0.3 release):
1) JDBC Metadata sequencer (POJO model is ready, working on extraction of metadata)
2) JAX-RS prototype.
IMO, we would need to start working on REST mapping for JCR resources. Basicaly, any implementation of http://jcp.org/en/jsr/summary?id=311 may be used as a core of the REST-JCR integration (RestEasy?)
There are at least few available implementations exists that we may review:
1) Sling project http://incubator.apache.org/sling/site/resources.html#Resources-JCRbasedR...)
2) Alfresco REST API for JCR at http://wiki.alfresco.com/wiki/HTTP_API#Alfresco_RESTful_API_Reference
3) Alfresco Content Management Interoperability Services (CMIS) API http://wiki.alfresco.com/wiki/CMIS_Web_Scripts_Reference
It would be nice to see as one of future features of DNA auto-discovery (zeroconf) of some resources as well as DNA repository self advertizing (for example - http://activemq.apache.org/zeroconf.html).
Best regards,
Sergiy
________________________________
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
To: dna-dev(a)lists.jboss.org
Sent: Thursday, 6 November, 2008 4:00:27 AM
Subject: dna-dev Digest, Vol 8, Issue 3
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. Preparing for the 0.3 release (Randall Hauch)
2. JBoss DNA 0.4 planning (Randall Hauch)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Nov 2008 12:18:59 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: [dna-dev] Preparing for the 0.3 release
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <92A505A6-0D05-47BF-813B-438181005D27(a)redhat.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
We're down to just a handful of outstanding issues targeted to 0.3,
and all of the big fish issues were completed. I'll be working my two
issues over the next few days, but I should be ready for releasing as
early as this week. Serge has the other outstanding issues, which are
all regarding the SVN connector. Serge, where do we stand on this?
Do you want more time to get some functionality finished, or is the
connector fairly close?
Anybody else have anything to discuss?
Best regards,
Randall
------------------------------
Message: 2
Date: Tue, 4 Nov 2008 12:37:05 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: [dna-dev] JBoss DNA 0.4 planning
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <9643F3D3-5E3F-4219-A492-6BC1F6196C73(a)redhat.com>
Content-Type: text/plain; charset="us-ascii"
Now that 0.3 is almost out the door, I'd like to start discussing the
goals for the next release.
I'd love to see the JCR implementation take more shape. Right now
it's read-only, so getting that much farther along would be
outstanding. Anybody interested? I think we could easily put several
people to work here. The graph API is pretty good, and should make
implementing JCR relatively straightforward. Any interest, Michael
Trezzi and Alexandre and Serge?
We need to add events to the connector framework. That should be
pretty straightforward. Also versioning, which will require a bit
more work. Plus, there are a couple of connectors that we may want to
start working on. This is something I'd be happy to continue with.
Serge P. also has expressed interest in working on some connectors (in
fact his SVN connector is coming along great!).
The CND sequencer could use some love and attention. Dan was stuck in
some ANLTR hell, and got pulled off onto a different project. Since
it uses ANTLR, maybe you might be interested in it, Alexandre?
We also have a need to start working on a REST/WebDAV layer that
allows other client apps to access a DNA repository. There's a couple
of things we can do, including looking at Apache Sling, or using
RESTeasy for a more simple implementation, or something else. Sergiy
and John both expressed interest in this.
Anything else?
We can either tackle several things at once and move them all
incrementally, or we can do more in just a few areas. Ideally, we're
looking at a 4-5 week cycle (finishing before the year-end holidays.)
A lot will depend on how much effort people might be able to dedicate
to the project.
Please respond with your thoughts and comments!
Best regards,
Randall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20081104/90ff822f/at...
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 8, Issue 3
*************************************
________________________________
Search 1000's of available singles in your area at the new Yahoo!7 Dating. Get Started._______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
________________________________
Make the switch to the world's best email. Get Yahoo!7 Mail.
Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20081118/926129d6/at...
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 8, Issue 11
**************************************
Make the switch to the world's best email. Get Yahoo!7 Mail! http://au.yahoo.com/y7mail
17 years, 1 month
- 1
- 0
Re: JBoss DNA 0.4 planning
by Sergey Litsenko
Hi All,
I've already started working on (not yet in SVN - will wait till 0.3 release):
1) JDBC Metadata sequencer (POJO model is ready, working on extraction of metadata)
2) JAX-RS prototype.
IMO, we would need to start working on REST mapping for JCR resources. Basicaly,
any implementation of http://jcp.org/en/jsr/summary?id=311 may be used
as a core of the REST-JCR integration (RestEasy?)
There are at least few available implementations exists that we may review:
1) Sling project http://incubator.apache.org/sling/site/resources.html#Resources-JCRbasedR...)
2) Alfresco REST API for JCR at http://wiki.alfresco.com/wiki/HTTP_API#Alfresco_RESTful_API_Reference
3) Alfresco Content Management Interoperability Services (CMIS) API http://wiki.alfresco.com/wiki/CMIS_Web_Scripts_Reference
It would be nice to see as one of future features of DNA auto-discovery (zeroconf) of some resources as well as DNA repository self advertizing (for example - http://activemq.apache.org/zeroconf.html).
Best regards,
Sergiy
________________________________
From: "dna-dev-request(a)lists.jboss.org" <dna-dev-request(a)lists.jboss.org>
To: dna-dev(a)lists.jboss.org
Sent: Thursday, 6 November, 2008 4:00:27 AM
Subject: dna-dev Digest, Vol 8, Issue 3
Send dna-dev mailing list submissions to
dna-dev(a)lists.jboss.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/dna-dev
or, via email, send a message with subject or body 'help' to
dna-dev-request(a)lists.jboss.org
You can reach the person managing the list at
dna-dev-owner(a)lists.jboss.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dna-dev digest..."
Today's Topics:
1. Preparing for the 0.3 release (Randall Hauch)
2. JBoss DNA 0.4 planning (Randall Hauch)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Nov 2008 12:18:59 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: [dna-dev] Preparing for the 0.3 release
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <92A505A6-0D05-47BF-813B-438181005D27(a)redhat.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
We're down to just a handful of outstanding issues targeted to 0.3,
and all of the big fish issues were completed. I'll be working my two
issues over the next few days, but I should be ready for releasing as
early as this week. Serge has the other outstanding issues, which are
all regarding the SVN connector. Serge, where do we stand on this?
Do you want more time to get some functionality finished, or is the
connector fairly close?
Anybody else have anything to discuss?
Best regards,
Randall
------------------------------
Message: 2
Date: Tue, 4 Nov 2008 12:37:05 -0600
From: Randall Hauch <rhauch(a)redhat.com>
Subject: [dna-dev] JBoss DNA 0.4 planning
To: JBoss DNA <dna-dev(a)lists.jboss.org>
Message-ID: <9643F3D3-5E3F-4219-A492-6BC1F6196C73(a)redhat.com>
Content-Type: text/plain; charset="us-ascii"
Now that 0.3 is almost out the door, I'd like to start discussing the
goals for the next release.
I'd love to see the JCR implementation take more shape. Right now
it's read-only, so getting that much farther along would be
outstanding. Anybody interested? I think we could easily put several
people to work here. The graph API is pretty good, and should make
implementing JCR relatively straightforward. Any interest, Michael
Trezzi and Alexandre and Serge?
We need to add events to the connector framework. That should be
pretty straightforward. Also versioning, which will require a bit
more work. Plus, there are a couple of connectors that we may want to
start working on. This is something I'd be happy to continue with.
Serge P. also has expressed interest in working on some connectors (in
fact his SVN connector is coming along great!).
The CND sequencer could use some love and attention. Dan was stuck in
some ANLTR hell, and got pulled off onto a different project. Since
it uses ANTLR, maybe you might be interested in it, Alexandre?
We also have a need to start working on a REST/WebDAV layer that
allows other client apps to access a DNA repository. There's a couple
of things we can do, including looking at Apache Sling, or using
RESTeasy for a more simple implementation, or something else. Sergiy
and John both expressed interest in this.
Anything else?
We can either tackle several things at once and move them all
incrementally, or we can do more in just a few areas. Ideally, we're
looking at a 4-5 week cycle (finishing before the year-end holidays.)
A lot will depend on how much effort people might be able to dedicate
to the project.
Please respond with your thoughts and comments!
Best regards,
Randall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/dna-dev/attachments/20081104/90ff822f/at...
------------------------------
_______________________________________________
dna-dev mailing list
dna-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/dna-dev
End of dna-dev Digest, Vol 8, Issue 3
*************************************
Find your perfect match today at the new Yahoo!7 Dating. Get Started http://au.dating.yahoo.com/?cid=53151&pid=1012
17 years, 1 month
- 2
- 4
JBoss DNA 0.3 is released
by Randall Hauch
JBoss DNA 0.3 has been released, and is available in the JBoss Maven
repository and our our project page's downloads area.
Congratulations, everyone!
This was our shortest cycle yet, and I think it was very successful.
We fixed several issues, pulled the XML sequencer out to its own
extension project, simplified a couple of internal framework, enhanced
the connector framework, and added a new graph API for those
components that sit on top of connectors. There's also a new section
in the Reference Guide's on how to write custom connectors (http://www.jboss.org/file-access/default/members/dna/freezone/docs/0.3/ma...
). We also got a good start on a new SVN connector. (My apologies if
I'm missing something).
Thanks to the whole team! Interest in JBoss DNA continues to grow,
and that's a testament to your hard work and desire to build a great
project.
Congratulations, and best regards.
Randall
17 years, 1 month
- 1
- 0
Calling all testers
by Randall Hauch
One of our latest issues (https://jira.jboss.org/jira/browse/DNA-231)
deals with an XML processing problem. I believe it has been fixed,
and I've verified it runs on OS-X (with Java 5 and Java 6) as well as
RHEL (on Java 5). So, the issue is now marked as 'resolved'.
However, before we close the issue, I'd like to verify it works on
more platforms. So, I'm calling on this group to run the full suite
of unit tests on your platform(s), with Java 5, Java 6 and/or Java 7.
Please post your results as a comment on https://jira.jboss.org/jira/browse/DNA-231
.
Thanks, and best regards,
Randall
17 years, 1 month
- 1
- 0