[jira] Commented: (CONNECTORS-93) add contributors to CHANGES.txt

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901700#action_12901700
 ] 

Karl Wright commented on CONNECTORS-93:
---

Looks good so far.
I'd also consider adding something about the change from LCF to ACF, and the 
associated package changes, since that will invalidate people's setups.


> add contributors to CHANGES.txt
> ---
>
> Key: CONNECTORS-93
> URL: https://issues.apache.org/jira/browse/CONNECTORS-93
> Project: Apache Connectors Framework
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robert Muir
> Attachments: CONNECTORS-93.patch
>
>
> As mentioned on the connectors-dev@ list (change the format of CHANGES.txt), 
> I propose we modify CHANGES.txt
> to give credit to contributors who have given bug reports, comments, patches, 
> etc.
> I'll volunteer to go thru the mail archives and jira issues that are marked 
> 'resolved' and upload a patch here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CONNECTORS-94) fix common localization traps

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901699#action_12901699
 ] 

Karl Wright commented on CONNECTORS-94:
---

Please contribute.  I'd like to review the places where you find these issues, 
especially getBytes() and toLowerCase()/toUpperCase(), because I thought we'd 
been quite careful about those.


> fix common localization traps
> -
>
> Key: CONNECTORS-94
> URL: https://issues.apache.org/jira/browse/CONNECTORS-94
> Project: Apache Connectors Framework
>  Issue Type: Task
>Reporter: Robert Muir
>
> Searching thru the LCF code, i found several uses of the following that 
> appear to be potentially dangerous:
> * getBytes() with no encoding: this is dangerous as the encoding is 
> completely unspecified. In most places this should likely mean "UTF-8"
> * getBytes("utf-8"): this is mostly a nitpick, but this alias is not 
> guaranteed to exist (see Charset docs). I suggest changing these all to 
> "UTF-8"
>   
> * String.toLowerCase()/String.toUpperCase() with no specified Locale, where 
> it appears the text is not used solely for display, but instead for 'caseless 
> matching'. I suggest changing these to use either the root Locale: new 
> Locale("") or even easier, Locale.ENGLISH. This way ACF does not have 
> surprising behavior on say a Turkish computer.
> I can contribute a patch to address these.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CONNECTORS-94) fix common localization traps

[Robert Muir (JIRA)]

fix common localization traps
-

 Key: CONNECTORS-94
 URL: https://issues.apache.org/jira/browse/CONNECTORS-94
 Project: Apache Connectors Framework
  Issue Type: Task
Reporter: Robert Muir


Searching thru the LCF code, i found several uses of the following that appear 
to be potentially dangerous:

* getBytes() with no encoding: this is dangerous as the encoding is completely 
unspecified. In most places this should likely mean "UTF-8"

* getBytes("utf-8"): this is mostly a nitpick, but this alias is not guaranteed 
to exist (see Charset docs). I suggest changing these all to "UTF-8"
  
* String.toLowerCase()/String.toUpperCase() with no specified Locale, where it 
appears the text is not used solely for display, but instead for 'caseless 
matching'. I suggest changing these to use either the root Locale: new 
Locale("") or even easier, Locale.ENGLISH. This way ACF does not have 
surprising behavior on say a Turkish computer.

I can contribute a patch to address these.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-93) add contributors to CHANGES.txt

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated CONNECTORS-93:
--

Attachment: CONNECTORS-93.patch

attached is a rough initial patch.

I formatted this in a similar way to Lucene/Solr.

I listed all the JIRA issues marked resolved (where it appeared there was a 
resolution resulting in actual changes). I then tried to associate these issues 
with any contributors of ideas/feedback/bug reports on the mailing lists or 
issues, and tried to give each one a short description (typically from the JIRA 
summary).

Please review and see if i forgot someone, spelled someones name incorrectly, 
or described an issue incorrectly (I probably made all of these mistakes).


> add contributors to CHANGES.txt
> ---
>
> Key: CONNECTORS-93
> URL: https://issues.apache.org/jira/browse/CONNECTORS-93
> Project: Apache Connectors Framework
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robert Muir
> Attachments: CONNECTORS-93.patch
>
>
> As mentioned on the connectors-dev@ list (change the format of CHANGES.txt), 
> I propose we modify CHANGES.txt
> to give credit to contributors who have given bug reports, comments, patches, 
> etc.
> I'll volunteer to go thru the mail archives and jira issues that are marked 
> 'resolved' and upload a patch here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: Need an opinion, on whether to change package or not

[karl.wright]

My apologies - I'm fairly new to this.  The procedures aren't yet ingrained. ;-)

Karl


From: gian...@gmail.com [gian...@gmail.com] On Behalf Of ext Gianugo Rabellino 
[gian...@rabellino.it]
Sent: Monday, August 23, 2010 5:30 PM
To: connectors-dev@incubator.apache.org
Subject: Re: Need an opinion, on whether to change package or not

On Sun, Aug 22, 2010 at 7:49 PM, Karl Wright  wrote:
> Consider this an official request for a vote.

Then please, next time mark it explicitly as such. This is usually
done, in Apache-land, by prefixing the subject with [VOTE]. This way
people who are in cursory-reading mode (like myself) won't be missing
an important decision point.

Thanks,

--
Gianugo

Re: Need an opinion, on whether to change package or not

[Gianugo Rabellino]

On Sun, Aug 22, 2010 at 7:49 PM, Karl Wright  wrote:
> Consider this an official request for a vote.

Then please, next time mark it explicitly as such. This is usually
done, in Apache-land, by prefixing the subject with [VOTE]. This way
people who are in cursory-reading mode (like myself) won't be missing
an important decision point.

Thanks,

-- 
Gianugo

Re: change the format of CHANGES.txt

[Jack Krupansky]

+1

-- Jack Krupansky

--
From: "Robert Muir" 
Sent: Monday, August 23, 2010 4:04 PM
To: 
Subject: change the format of CHANGES.txt


Hello,

I wanted to suggest that we slightly alter the format of CHANGES.txt.
Most important I think is to add the names of non-committers who 
contribute

any patches, JIRA comments, reports of bugs on the user list, etc to the
issue.

This is how the CHANGES.txt is formulated for Lucene and Solr and I think 
it
encourages contributors to come back, because they get some credit for 
their

contributions.

Any thoughts? I think it would be really good to add all contributors to 
any

jira issues before the first release especially.

--
Robert Muir
rcm...@gmail.com

Re: change the format of CHANGES.txt

[Grant Ingersoll]

I think this also underscores something we as an Incubating community should 
think about in terms of process.  Obviously, it is great to give credit, but 
sometimes we also need to give people a chance to contribute, too.  Even on 
seemingly trivial things (I don't have anything specific in mind) sometimes it 
makes sense to wait before making the change.  For instance, say someone opens 
an issue, it might work to say something like "Hey, great catch.  Could you 
generate a patch?  See 
https://cwiki.apache.org/confluence/display/CONNECTORS/HowToContribute for info 
on how to do that."  If they do give one, then commit it promptly and give them 
credit.  If not, let it sit for a few days before making the change to see if 
someone else steps up.  Sure, it slows down some things, but it gives people a 
chance to help out and be involved.  These smaller issues are also a great way 
for us "newbie" committers to get our hands dirty with the code.

-Grant


On Aug 23, 2010, at 4:46 PM,  wrote:

> +1 from me.
> Karl
> 
> -Original Message-
> From: ext Robert Muir [mailto:rcm...@gmail.com] 
> Sent: Monday, August 23, 2010 4:05 PM
> To: connectors-dev@incubator.apache.org
> Subject: change the format of CHANGES.txt
> 
> Hello,
> 
> I wanted to suggest that we slightly alter the format of CHANGES.txt.
> Most important I think is to add the names of non-committers who contribute
> any patches, JIRA comments, reports of bugs on the user list, etc to the
> issue.
> 
> This is how the CHANGES.txt is formulated for Lucene and Solr and I think it
> encourages contributors to come back, because they get some credit for their
> contributions.
> 
> Any thoughts? I think it would be really good to add all contributors to any
> jira issues before the first release especially.
> 
> -- 
> Robert Muir
> rcm...@gmail.com

RE: change the format of CHANGES.txt

[karl.wright]

+1 from me.
Karl

-Original Message-
From: ext Robert Muir [mailto:rcm...@gmail.com] 
Sent: Monday, August 23, 2010 4:05 PM
To: connectors-dev@incubator.apache.org
Subject: change the format of CHANGES.txt

Hello,

I wanted to suggest that we slightly alter the format of CHANGES.txt.
Most important I think is to add the names of non-committers who contribute
any patches, JIRA comments, reports of bugs on the user list, etc to the
issue.

This is how the CHANGES.txt is formulated for Lucene and Solr and I think it
encourages contributors to come back, because they get some credit for their
contributions.

Any thoughts? I think it would be really good to add all contributors to any
jira issues before the first release especially.

-- 
Robert Muir
rcm...@gmail.com

Re: change the format of CHANGES.txt

[Robert Muir]

ok I created https://issues.apache.org/jira/browse/CONNECTORS-93

I can start going thru
mail archives and issues that are resolved and look for contributors. If you
have some free time and want to help, please feel free and just
comment/upload on the issue.

I think this is really important before any release happens.

On Mon, Aug 23, 2010 at 4:31 PM, Simon Willnauer <
simon.willna...@googlemail.com> wrote:

> +1
>
> On Mon, Aug 23, 2010 at 10:18 PM, Grant Ingersoll 
> wrote:
> >
> > On Aug 23, 2010, at 4:04 PM, Robert Muir wrote:
> >
> >> Hello,
> >>
> >> I wanted to suggest that we slightly alter the format of CHANGES.txt.
> >> Most important I think is to add the names of non-committers who
> contribute
> >> any patches, JIRA comments, reports of bugs on the user list, etc to the
> >> issue.
> >>
> >> This is how the CHANGES.txt is formulated for Lucene and Solr and I
> think it
> >> encourages contributors to come back, because they get some credit for
> their
> >> contributions.
> >>
> >> Any thoughts? I think it would be really good to add all contributors to
> any
> >> jira issues before the first release especially.
> >
> > +1.  We definitely should be giving credit to those who help.
>



-- 
Robert Muir
rcm...@gmail.com

[jira] Created: (CONNECTORS-93) add contributors to CHANGES.txt

[Robert Muir (JIRA)]

add contributors to CHANGES.txt
---

 Key: CONNECTORS-93
 URL: https://issues.apache.org/jira/browse/CONNECTORS-93
 Project: Apache Connectors Framework
  Issue Type: Task
  Components: Documentation
Reporter: Robert Muir


As mentioned on the connectors-dev@ list (change the format of CHANGES.txt), I 
propose we modify CHANGES.txt
to give credit to contributors who have given bug reports, comments, patches, 
etc.

I'll volunteer to go thru the mail archives and jira issues that are marked 
'resolved' and upload a patch here.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: change the format of CHANGES.txt

[Simon Willnauer]

+1

On Mon, Aug 23, 2010 at 10:18 PM, Grant Ingersoll  wrote:
>
> On Aug 23, 2010, at 4:04 PM, Robert Muir wrote:
>
>> Hello,
>>
>> I wanted to suggest that we slightly alter the format of CHANGES.txt.
>> Most important I think is to add the names of non-committers who contribute
>> any patches, JIRA comments, reports of bugs on the user list, etc to the
>> issue.
>>
>> This is how the CHANGES.txt is formulated for Lucene and Solr and I think it
>> encourages contributors to come back, because they get some credit for their
>> contributions.
>>
>> Any thoughts? I think it would be really good to add all contributors to any
>> jira issues before the first release especially.
>
> +1.  We definitely should be giving credit to those who help.

Re: change the format of CHANGES.txt

[Grant Ingersoll]

On Aug 23, 2010, at 4:04 PM, Robert Muir wrote:

> Hello,
> 
> I wanted to suggest that we slightly alter the format of CHANGES.txt.
> Most important I think is to add the names of non-committers who contribute
> any patches, JIRA comments, reports of bugs on the user list, etc to the
> issue.
> 
> This is how the CHANGES.txt is formulated for Lucene and Solr and I think it
> encourages contributors to come back, because they get some credit for their
> contributions.
> 
> Any thoughts? I think it would be really good to add all contributors to any
> jira issues before the first release especially.

+1.  We definitely should be giving credit to those who help.

change the format of CHANGES.txt

[Robert Muir]

Hello,

I wanted to suggest that we slightly alter the format of CHANGES.txt.
Most important I think is to add the names of non-committers who contribute
any patches, JIRA comments, reports of bugs on the user list, etc to the
issue.

This is how the CHANGES.txt is formulated for Lucene and Solr and I think it
encourages contributors to come back, because they get some credit for their
contributions.

Any thoughts? I think it would be really good to add all contributors to any
jira issues before the first release especially.

-- 
Robert Muir
rcm...@gmail.com

Wiki space name

[Karl Wright]

Hi,

I've discovered where, at least, you are supposed to change the name of a
Wiki space.  There's a "browse project" icon from the "Dashboard" page, and
within that there's an "Advanced" tab.  That tab shows the "Space name" as
part of the "Space details".

Unfortunately, I don't seem to have the ability to edit the "Space details"
for the "CONNECTORS" space.  The person who set this up was Jukka
(Zitting).  Jukka, do you want to do this?  Does anyone else have
permission?

Karl

[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901436#action_12901436
 ] 

Karl Wright commented on CONNECTORS-92:
---

Re: build preferences

Continuing to have an ant build is actually pretty important for some modes of 
delivery.  I'm specifically thinking of debian and Ubuntu packaging here.  
Maven does not work well with these packaging schemes because it's too 
all-encompassing.  We therefore need a way of doing builds locally, without 
pulling things down from a mirror.

My original thought was that we'd have multiple layers - ant  being the most 
basic, with a maven wrapper available to pull down what the ant build needed, 
and have the maven build call ant underneath.  I don't know how realistic that 
is, but it does solve all the problems if it can be done that way.


> Move from ant to maven or other build system with decent library management
> ---
>
> Key: CONNECTORS-92
> URL: https://issues.apache.org/jira/browse/CONNECTORS-92
> Project: Apache Connectors Framework
>  Issue Type: Wish
>  Components: Build
>Reporter: Jettro Coenradie
> Attachments: Screen shot 2010-08-23 at 16.31.07.png
>
>
> I am looking at the current project structure. If we want to make another 
> build tool available I think we need to change the directory structure. I 
> tried to place a suggestion in an image. Can you please have a look at it. If 
> we agree that this is a good way to go, than I will continue to work on a 
> patch. Which might be a bit hard with all these changing directories, but 
> I'll do my best to at least get an idea whether it would be working.
> So I have three questions:
> - Do you want to move to maven or put maven next to ant?
> - Do you prefer another build mechanism [ant with ivy, gradle, maven3]
> - Do you have an idea about the amount of scripts that need to be changed if 
> we change the project structure
> The image of a possible project layout (that is based on the maven standards) 
> is attached to the issue

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CONNECTORS-92) Move from ant to maven or other build system with decent library management

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901432#action_12901432
 ] 

Karl Wright commented on CONNECTORS-92:
---

This proposed change has a number of features I don't  understand the reasons 
for:

(1) Breaking up modules and putting pieces of that all over the place
(2) Taking jetty-runner out of framework
(3) Introducing a "src" directory under each of the framework components
(4) Moving the tests so far away from the code they are related to

Can you describe your logic for this reorganization?


> Move from ant to maven or other build system with decent library management
> ---
>
> Key: CONNECTORS-92
> URL: https://issues.apache.org/jira/browse/CONNECTORS-92
> Project: Apache Connectors Framework
>  Issue Type: Wish
>  Components: Build
>Reporter: Jettro Coenradie
> Attachments: Screen shot 2010-08-23 at 16.31.07.png
>
>
> I am looking at the current project structure. If we want to make another 
> build tool available I think we need to change the directory structure. I 
> tried to place a suggestion in an image. Can you please have a look at it. If 
> we agree that this is a good way to go, than I will continue to work on a 
> patch. Which might be a bit hard with all these changing directories, but 
> I'll do my best to at least get an idea whether it would be working.
> So I have three questions:
> - Do you want to move to maven or put maven next to ant?
> - Do you prefer another build mechanism [ant with ivy, gradle, maven3]
> - Do you have an idea about the amount of scripts that need to be changed if 
> we change the project structure
> The image of a possible project layout (that is based on the maven standards) 
> is attached to the issue

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: improving the build

[Jettro Coenradie]

That is a good idea, maven can call ant to execute tasks. The jars are
available in the maven repository and should therefore not be to hard to
make available to the ant build. Would be nice to have an idea of the amount
of scripts that we need to alter to make this happen. I also see a lot of
shell scripts that might need attention if we change this.

- Jettro

On Mon, Aug 23, 2010 at 4:52 PM,  wrote:

> Re: build preferences
>
> Continuing to have an ant build is actually pretty important for some modes
> of delivery.  I'm specifically thinking of debian and Ubuntu packaging here.
>  Maven does not work well with these packaging schemes because it's too
> all-encompassing.  We therefore need a way of doing builds locally, without
> pulling things down from a mirror.
>
> My original thought was that we'd have multiple layers - ant  being the
> most basic, with a maven wrapper available to pull down what the ant build
> needed, and have the maven build call ant underneath.  I don't know how
> realistic that is, but it does solve all the problems if it can be done that
> way.
>
> Karl
>
> From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On
> Behalf Of ext Jettro Coenradie
> Sent: Monday, August 23, 2010 10:43 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: improving the build
>
> I am looking at the current project structure. If we want to make another
> build tool available I think we need to change the directory structure. I
> tried to place a suggestion in an image. Can you please have a look at it.
> If we agree that this is a good way to go, than I will continue to work on a
> patch. Which might be a bit hard with all these changing directories, but
> I'll do my best to at least get an idea whether it would be working.
>
> So I have three questions:
> - Do you want to move to maven or put maven next to ant?
> - Do you prefer another build mechanism [ant with ivy, gradle, maven3]
> - Do you have an idea about the amount of scripts that need to be changed
> if we change the project structure
>
> The image of a possible project layout (that is based on the maven
> standards) is attached to the mail
>
> Jettro
> On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie <
> jettro.coenra...@gridshore.nl>
> wrote:
> We could use something like profiles in maven. That way you can easily
> configure which projects to compile and which not. That would include tests.
>
> I will have a look at it and come up with a proposal.
>
> On Mon, Aug 16, 2010 at 2:49 PM,  karl.wri...@nokia.com>> wrote:
> Re maven: There is a wiki page describing the Maven dependencies; somebody
> needs to tackle this.  If you want to volunteer, we'd love to hear your
> proposal.  However, please remember that you really must be sure to retain
> the connector conditional compilation structure as is currently in place,
> for license reasons.
>
> Re unit tests: The Junit test code was actually placed carefully based on
> the above considerations.  In other words, you can't run a test that
> requires connectors x,y,z unless those connectors have actually been built.
>  Similarly, you may think in terms of testing a specific connector by
> including tests for that connector, but those tests cannot use any OTHER
> connectors or you will break the build, which is why any tests that use
> multiple connectors must be at the module level.
>
> Karl
>
> -Original Message-
> From: jettro.coenra...@gmail.com
> [mailto:jettro.coenra...@gmail.com] On
> Behalf Of ext Jettro Coenradie
> Sent: Monday, August 16, 2010 8:21 AM
> To: connectors-dev@incubator.apache.org connectors-dev@incubator.apache.org>
> Subject: improving the build
>
> Hi,
> I think the current download is pretty big. Is there is good reason that we
> do not use something like maven. Or at least, if you do not like maven, ivy
> to share dependencies between projects. Also enforces you to use libraries
> that are generally available.
>
> I would also love to have the (unit)tests closer to the actual code, hard
> to
> locate the tests at the moment
>
> Would like to hear the thoughts of the developers
>
> regards
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

[jira] Updated: (CONNECTORS-92) Move from ant to maven or other build system with decent library management

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-92:
---

Attachment: Screen shot 2010-08-23 at 16.31.07.png

idea of the directory structure

> Move from ant to maven or other build system with decent library management
> ---
>
> Key: CONNECTORS-92
> URL: https://issues.apache.org/jira/browse/CONNECTORS-92
> Project: Apache Connectors Framework
>  Issue Type: Wish
>  Components: Build
>Reporter: Jettro Coenradie
> Attachments: Screen shot 2010-08-23 at 16.31.07.png
>
>
> I am looking at the current project structure. If we want to make another 
> build tool available I think we need to change the directory structure. I 
> tried to place a suggestion in an image. Can you please have a look at it. If 
> we agree that this is a good way to go, than I will continue to work on a 
> patch. Which might be a bit hard with all these changing directories, but 
> I'll do my best to at least get an idea whether it would be working.
> So I have three questions:
> - Do you want to move to maven or put maven next to ant?
> - Do you prefer another build mechanism [ant with ivy, gradle, maven3]
> - Do you have an idea about the amount of scripts that need to be changed if 
> we change the project structure
> The image of a possible project layout (that is based on the maven standards) 
> is attached to the issue

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (CONNECTORS-92) Move from ant to maven or other build system with decent library management

[Jettro Coenradie (JIRA)]

Move from ant to maven or other build system with decent library management
---

 Key: CONNECTORS-92
 URL: https://issues.apache.org/jira/browse/CONNECTORS-92
 Project: Apache Connectors Framework
  Issue Type: Wish
  Components: Build
Reporter: Jettro Coenradie
 Attachments: Screen shot 2010-08-23 at 16.31.07.png

I am looking at the current project structure. If we want to make another build 
tool available I think we need to change the directory structure. I tried to 
place a suggestion in an image. Can you please have a look at it. If we agree 
that this is a good way to go, than I will continue to work on a patch. Which 
might be a bit hard with all these changing directories, but I'll do my best to 
at least get an idea whether it would be working.

So I have three questions:
- Do you want to move to maven or put maven next to ant?
- Do you prefer another build mechanism [ant with ivy, gradle, maven3]
- Do you have an idea about the amount of scripts that need to be changed if we 
change the project structure

The image of a possible project layout (that is based on the maven standards) 
is attached to the issue


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: improving the build

[karl.wright]

Re: build preferences

Continuing to have an ant build is actually pretty important for some modes of 
delivery.  I'm specifically thinking of debian and Ubuntu packaging here.  
Maven does not work well with these packaging schemes because it's too 
all-encompassing.  We therefore need a way of doing builds locally, without 
pulling things down from a mirror.

My original thought was that we'd have multiple layers - ant  being the most 
basic, with a maven wrapper available to pull down what the ant build needed, 
and have the maven build call ant underneath.  I don't know how realistic that 
is, but it does solve all the problems if it can be done that way.

Karl

From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf 
Of ext Jettro Coenradie
Sent: Monday, August 23, 2010 10:43 AM
To: connectors-dev@incubator.apache.org
Subject: Re: improving the build

I am looking at the current project structure. If we want to make another build 
tool available I think we need to change the directory structure. I tried to 
place a suggestion in an image. Can you please have a look at it. If we agree 
that this is a good way to go, than I will continue to work on a patch. Which 
might be a bit hard with all these changing directories, but I'll do my best to 
at least get an idea whether it would be working.

So I have three questions:
- Do you want to move to maven or put maven next to ant?
- Do you prefer another build mechanism [ant with ivy, gradle, maven3]
- Do you have an idea about the amount of scripts that need to be changed if we 
change the project structure

The image of a possible project layout (that is based on the maven standards) 
is attached to the mail

Jettro
On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie 
mailto:jettro.coenra...@gridshore.nl>> wrote:
We could use something like profiles in maven. That way you can easily 
configure which projects to compile and which not. That would include tests.

I will have a look at it and come up with a proposal.

On Mon, Aug 16, 2010 at 2:49 PM, 
mailto:karl.wri...@nokia.com>> wrote:
Re maven: There is a wiki page describing the Maven dependencies; somebody 
needs to tackle this.  If you want to volunteer, we'd love to hear your 
proposal.  However, please remember that you really must be sure to retain the 
connector conditional compilation structure as is currently in place, for 
license reasons.

Re unit tests: The Junit test code was actually placed carefully based on the 
above considerations.  In other words, you can't run a test that requires 
connectors x,y,z unless those connectors have actually been built.  Similarly, 
you may think in terms of testing a specific connector by including tests for 
that connector, but those tests cannot use any OTHER connectors or you will 
break the build, which is why any tests that use multiple connectors must be at 
the module level.

Karl

-Original Message-
From: jettro.coenra...@gmail.com 
[mailto:jettro.coenra...@gmail.com] On 
Behalf Of ext Jettro Coenradie
Sent: Monday, August 16, 2010 8:21 AM
To: 
connectors-dev@incubator.apache.org
Subject: improving the build

Hi,
I think the current download is pretty big. Is there is good reason that we
do not use something like maven. Or at least, if you do not like maven, ivy
to share dependencies between projects. Also enforces you to use libraries
that are generally available.

I would also love to have the (unit)tests closer to the actual code, hard to
locate the tests at the moment

Would like to hear the thoughts of the developers

regards

--
Jettro Coenradie
http://www.gridshore.nl



--
Jettro Coenradie
http://www.gridshore.nl



--
Jettro Coenradie
http://www.gridshore.nl

RE: improving the build

[karl.wright]

The image didn't come through, I'm afraid.
There may already be a Maven ticket in jira.  If you can't find it, please 
create one.  Attach your image to the ticket, and your proposal, and we'll all 
have a look at it.

Karl

From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf 
Of ext Jettro Coenradie
Sent: Monday, August 23, 2010 10:43 AM
To: connectors-dev@incubator.apache.org
Subject: Re: improving the build

I am looking at the current project structure. If we want to make another build 
tool available I think we need to change the directory structure. I tried to 
place a suggestion in an image. Can you please have a look at it. If we agree 
that this is a good way to go, than I will continue to work on a patch. Which 
might be a bit hard with all these changing directories, but I'll do my best to 
at least get an idea whether it would be working.

So I have three questions:
- Do you want to move to maven or put maven next to ant?
- Do you prefer another build mechanism [ant with ivy, gradle, maven3]
- Do you have an idea about the amount of scripts that need to be changed if we 
change the project structure

The image of a possible project layout (that is based on the maven standards) 
is attached to the mail

Jettro
On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie 
mailto:jettro.coenra...@gridshore.nl>> wrote:
We could use something like profiles in maven. That way you can easily 
configure which projects to compile and which not. That would include tests.

I will have a look at it and come up with a proposal.

On Mon, Aug 16, 2010 at 2:49 PM, 
mailto:karl.wri...@nokia.com>> wrote:
Re maven: There is a wiki page describing the Maven dependencies; somebody 
needs to tackle this.  If you want to volunteer, we'd love to hear your 
proposal.  However, please remember that you really must be sure to retain the 
connector conditional compilation structure as is currently in place, for 
license reasons.

Re unit tests: The Junit test code was actually placed carefully based on the 
above considerations.  In other words, you can't run a test that requires 
connectors x,y,z unless those connectors have actually been built.  Similarly, 
you may think in terms of testing a specific connector by including tests for 
that connector, but those tests cannot use any OTHER connectors or you will 
break the build, which is why any tests that use multiple connectors must be at 
the module level.

Karl

-Original Message-
From: jettro.coenra...@gmail.com 
[mailto:jettro.coenra...@gmail.com] On 
Behalf Of ext Jettro Coenradie
Sent: Monday, August 16, 2010 8:21 AM
To: 
connectors-dev@incubator.apache.org
Subject: improving the build

Hi,
I think the current download is pretty big. Is there is good reason that we
do not use something like maven. Or at least, if you do not like maven, ivy
to share dependencies between projects. Also enforces you to use libraries
that are generally available.

I would also love to have the (unit)tests closer to the actual code, hard to
locate the tests at the moment

Would like to hear the thoughts of the developers

regards

--
Jettro Coenradie
http://www.gridshore.nl



--
Jettro Coenradie
http://www.gridshore.nl



--
Jettro Coenradie
http://www.gridshore.nl

Re: improving the build

[Jettro Coenradie]

I am looking at the current project structure. If we want to make another
build tool available I think we need to change the directory structure. I
tried to place a suggestion in an image. Can you please have a look at it.
If we agree that this is a good way to go, than I will continue to work on a
patch. Which might be a bit hard with all these changing directories, but
I'll do my best to at least get an idea whether it would be working.

So I have three questions:
- Do you want to move to maven or put maven next to ant?
- Do you prefer another build mechanism [ant with ivy, gradle, maven3]
- Do you have an idea about the amount of scripts that need to be changed if
we change the project structure

The image of a possible project layout (that is based on the maven
standards) is attached to the mail

Jettro

On Mon, Aug 16, 2010 at 3:12 PM, Jettro Coenradie <
jettro.coenra...@gridshore.nl> wrote:

> We could use something like profiles in maven. That way you can easily
> configure which projects to compile and which not. That would include tests.
>
> I will have a look at it and come up with a proposal.
>
>
> On Mon, Aug 16, 2010 at 2:49 PM,  wrote:
>
>> Re maven: There is a wiki page describing the Maven dependencies; somebody
>> needs to tackle this.  If you want to volunteer, we'd love to hear your
>> proposal.  However, please remember that you really must be sure to retain
>> the connector conditional compilation structure as is currently in place,
>> for license reasons.
>>
>> Re unit tests: The Junit test code was actually placed carefully based on
>> the above considerations.  In other words, you can't run a test that
>> requires connectors x,y,z unless those connectors have actually been built.
>>  Similarly, you may think in terms of testing a specific connector by
>> including tests for that connector, but those tests cannot use any OTHER
>> connectors or you will break the build, which is why any tests that use
>> multiple connectors must be at the module level.
>>
>> Karl
>>
>> -Original Message-
>> From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On
>> Behalf Of ext Jettro Coenradie
>> Sent: Monday, August 16, 2010 8:21 AM
>> To: connectors-dev@incubator.apache.org
>> Subject: improving the build
>>
>> Hi,
>> I think the current download is pretty big. Is there is good reason that
>> we
>> do not use something like maven. Or at least, if you do not like maven,
>> ivy
>> to share dependencies between projects. Also enforces you to use libraries
>> that are generally available.
>>
>> I would also love to have the (unit)tests closer to the actual code, hard
>> to
>> locate the tests at the moment
>>
>> Would like to hear the thoughts of the developers
>>
>> regards
>>
>> --
>> Jettro Coenradie
>> http://www.gridshore.nl
>>
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

Re: Question about the json library

[Jettro Coenradie]

I know maven is another issue, but it is nice if the version is available
through a maven repository. Than other build tools can find it as well.

It is available for download through:
http://mvnrepository.com/artifact/org.json/json

or from the central maven repo:
http://repo2.maven.org/maven2/org/json/json/20090211/json-20090211.jar

Jettro

On Mon, Aug 23, 2010 at 4:16 PM,  wrote:

> The sources were downloaded from www.json.org, and are licensed
> accordingly.  There is no build available from www.json.org.  If you know
> of a prebuilt version of these sources, by all means point us at it.
>
> Mavenization is a different issue, and will have to be done independently.
>
> Karl
>
> -Original Message-
> From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On
> Behalf Of ext Jettro Coenradie
> Sent: Monday, August 23, 2010 10:04 AM
> To: connectors-dev@incubator.apache.org
> Subject: Question about the json library
>
> I am looking at the classes that come with the current trunk checkout and I
> see that a custom jar of json is created. Can someone explain why this is?
> Could we also take one from a maven repository?
>
> thanks,
> Jettro
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

RE: Question about the json library

[karl.wright]

The sources were downloaded from www.json.org, and are licensed accordingly.  
There is no build available from www.json.org.  If you know of a prebuilt 
version of these sources, by all means point us at it.

Mavenization is a different issue, and will have to be done independently.

Karl

-Original Message-
From: jettro.coenra...@gmail.com [mailto:jettro.coenra...@gmail.com] On Behalf 
Of ext Jettro Coenradie
Sent: Monday, August 23, 2010 10:04 AM
To: connectors-dev@incubator.apache.org
Subject: Question about the json library

I am looking at the classes that come with the current trunk checkout and I
see that a custom jar of json is created. Can someone explain why this is?
Could we also take one from a maven repository?

thanks,
Jettro

-- 
Jettro Coenradie
http://www.gridshore.nl

Question about the json library

[Jettro Coenradie]

I am looking at the classes that come with the current trunk checkout and I
see that a custom jar of json is created. Can someone explain why this is?
Could we also take one from a maven repository?

thanks,
Jettro

-- 
Jettro Coenradie
http://www.gridshore.nl

[jira] Resolved: (CONNECTORS-91) Making the initialization commands more useable

[Karl Wright (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright resolved CONNECTORS-91.
---

Resolution: Fixed

Patch committed.
r988101.


> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
>Assignee: Karl Wright
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch, 
> change_commands_with_system_err_println.patch, 
> change_commands_with_system_err_println_v2.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CONNECTORS-91) Making the initialization commands more useable

[Karl Wright (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Wright reassigned CONNECTORS-91:
-

Assignee: Karl Wright

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
>Assignee: Karl Wright
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch, 
> change_commands_with_system_err_println.patch, 
> change_commands_with_system_err_println_v2.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Attachment: change_commands_with_system_err_println_v2.patch

Sorry about the errors, I was a little bit to quick. I double checked all 
locations of printing the messages and the messages themselves. They should all 
be fine now.

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch, 
> change_commands_with_system_err_println.patch, 
> change_commands_with_system_err_println_v2.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901336#action_12901336
 ] 

Karl Wright commented on CONNECTORS-91:
---

I looked at this.  The patch seems correct for some classes, but for others it 
is clearly incorrect, e.g. SynchronizeAll:

 {
   System.err.println("Usage: SynchronizeAll");
   System.exit(1);
+  System.err.println("Successfully synchronized all agents");
 }

Can you review your change for accuracy please?

Also, responding to the logging change - the log settings are global, and we 
are trying for the least amount of setup work necessary to achieve a functional 
system.  Clearly, all log messages to stderr is not going to be reasonable for 
people doing real crawls, so we'd need some way to segregate command output in 
order to direct it differently than everything else, which implies at the least 
you'd want a different logger, and then you'd also want to revise the 
documented log4j properties, if you think we should go that route.  

Re: testing.  The testing you've done so far is best we can do at the moment, 
unless you'd also like to write some unit tests.   I don't think this would be 
terribly difficult, but once again it would be time consuming. ;-)


> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch, 
> change_commands_with_system_err_println.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need an opinion, on whether to change package or not

[Jettro Coenradie]

Cool, thanks

I don't want to be a pain, but trying to help improve the end result. And of
course I understand the project has a history and I know not everybody
thinks like me :-)

Jettro

On Mon, Aug 23, 2010 at 11:46 AM,  wrote:

> In any open-source project there is expected to be some differences in
> individual coding styles.  There is often also incomplete understanding of
> the reasoning behind the multitude of architectural decisions made during
> development, or the history of the project.  It is thus important to be
> pragmatic, and therefore each issue or question is basically its own topic,
> evaluated on its own merits.
>
> Probably the best way to deal with each *individual* concern or question is
> to open a jira ticket expressing that concern.  Discussion should then be
> done within the context of that ticket.  There is no guarantee, of course,
> that the ticket will be acted upon, but at least it will be discussed.
>
> Karl
>
> 
> From: jettro.coenra...@gmail.com [jettro.coenra...@gmail.com] On Behalf Of
> ext Jettro Coenradie [jettro.coenra...@gridshore.nl]
> Sent: Monday, August 23, 2010 5:17 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Need an opinion, on whether to change package or not
>
> I can understand that it is harder to do. Therefore it is better notto do
> it
> right now. I do not agree with you that it is easier to move files from one
> package to another. The fact that these classes have different impact
> should
> make you think before moving the classes. I would like to discuss on some
> of
> these design/code issues more as well. What is the best way to do this? Ask
> a question per topic to share opinions?
>
> thanks Jettro
>
> On Mon, Aug 23, 2010 at 10:54 AM,  wrote:
>
> > Unfortunately that is way harder to do using the python scripts I have
> > developed for this purpose.  Also, the reason the LCF root class appears
> in
> > different packages has to do with the relative ease that grants to moving
> > classes between the various acf jars.  So I'd consider this proposed
> change
> > to be controversial, and I don't think we should layer it in without
> > separate consideration.
> >
> > Karl
> >
> > 
> > From: ext Simon Willnauer [simon.willna...@googlemail.com]
> > Sent: Monday, August 23, 2010 4:40 AM
> > To: connectors-dev@incubator.apache.org
> > Subject: Re: Need an opinion, on whether to change package or not
> >
> > On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie
> >  wrote:
> > > If we are changing stuff can we also use more descriptive names. Not
> Use
> > LCF
> > > 4 to 5 times in a different Package. Use something like ACFAgent and
> > > ACFCrawler
> > +1  for that too!
> >
> > simon
> > >
> > > On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
> > > jettro.coenra...@gridshore.nl> wrote:
> > >
> > >> +1 for a complete change
> > >>
> > >>
> > >> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller  > >wrote:
> > >>
> > >>> +1 to renaming the package - nows the time.
> > >>>
> > >>> - Mark
> > >>>
> > >>> http://www.lucidimagination.com (mobile)
> > >>>
> > >>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
> > >>> jack.krupan...@lucidimagination.com> wrote:
> > >>>
> > >>> > +1
> > >>> >
> > >>> > -- Jack Krupansky
> > >>> >
> > >>> > --
> > >>> > From: "Karl Wright" 
> > >>> > Sent: Sunday, August 22, 2010 1:49 PM
> > >>> > To: "connectors-dev" 
> > >>> > Subject: Need an opinion, on whether to change package or not
> > >>> >
> > >>> >> Consider this an official request for a vote.
> > >>> >>
> > >>> >> +1 indicates you think we should change the following in the
> source
> > >>> code, as
> > >>> >> soon as is practical:
> > >>> >>
> > >>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
> > >>> >> All classes LCF.java and LCFException.java should change to
> ACF.java
> > >>> and
> > >>> >> ACFException.java
> > >>> >>
> > >>> >> Bear in mind that users of ACF/LCF who currently have existing
> > database
> > >>> >> instances will need to reinitialize those instances if we do this
> > >>> change.
> > >>> >> This is because the class names of connectors are stored in the
> > >>> database
> > >>> >> when the connector is registered.
> > >>> >>
> > >>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the
> disruption.
> > >>>  But I
> > >>> >> will of course abide by the consensus.)
> > >>> >>
> > >>> >> Vote will be considered closed by Wednesday evening, so vote early
> > (and
> > >>> >> often. ;-))
> > >>> >> Karl
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Jettro Coenradie
> > >> http://www.gridshore.nl
> > >>
> > >
> > >
> > >
> > > --
> > > Jettro Coenradie
> > > http://www.gridshore.nl
> > >
> >
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

Results so far of package rename vote

[Karl Wright]

The vote so far is so overwhelmingly in favor of renaming all the packages
that unless I hear anything to the contrary by end of business today I'll go
ahead with the change.

Karl

RE: Need an opinion, on whether to change package or not

[karl.wright]

In any open-source project there is expected to be some differences in 
individual coding styles.  There is often also incomplete understanding of the 
reasoning behind the multitude of architectural decisions made during 
development, or the history of the project.  It is thus important to be 
pragmatic, and therefore each issue or question is basically its own topic, 
evaluated on its own merits.

Probably the best way to deal with each *individual* concern or question is to 
open a jira ticket expressing that concern.  Discussion should then be done 
within the context of that ticket.  There is no guarantee, of course, that the 
ticket will be acted upon, but at least it will be discussed.

Karl


From: jettro.coenra...@gmail.com [jettro.coenra...@gmail.com] On Behalf Of ext 
Jettro Coenradie [jettro.coenra...@gridshore.nl]
Sent: Monday, August 23, 2010 5:17 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Need an opinion, on whether to change package or not

I can understand that it is harder to do. Therefore it is better notto do it
right now. I do not agree with you that it is easier to move files from one
package to another. The fact that these classes have different impact should
make you think before moving the classes. I would like to discuss on some of
these design/code issues more as well. What is the best way to do this? Ask
a question per topic to share opinions?

thanks Jettro

On Mon, Aug 23, 2010 at 10:54 AM,  wrote:

> Unfortunately that is way harder to do using the python scripts I have
> developed for this purpose.  Also, the reason the LCF root class appears in
> different packages has to do with the relative ease that grants to moving
> classes between the various acf jars.  So I'd consider this proposed change
> to be controversial, and I don't think we should layer it in without
> separate consideration.
>
> Karl
>
> 
> From: ext Simon Willnauer [simon.willna...@googlemail.com]
> Sent: Monday, August 23, 2010 4:40 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Need an opinion, on whether to change package or not
>
> On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie
>  wrote:
> > If we are changing stuff can we also use more descriptive names. Not Use
> LCF
> > 4 to 5 times in a different Package. Use something like ACFAgent and
> > ACFCrawler
> +1  for that too!
>
> simon
> >
> > On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
> > jettro.coenra...@gridshore.nl> wrote:
> >
> >> +1 for a complete change
> >>
> >>
> >> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller  >wrote:
> >>
> >>> +1 to renaming the package - nows the time.
> >>>
> >>> - Mark
> >>>
> >>> http://www.lucidimagination.com (mobile)
> >>>
> >>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
> >>> jack.krupan...@lucidimagination.com> wrote:
> >>>
> >>> > +1
> >>> >
> >>> > -- Jack Krupansky
> >>> >
> >>> > --
> >>> > From: "Karl Wright" 
> >>> > Sent: Sunday, August 22, 2010 1:49 PM
> >>> > To: "connectors-dev" 
> >>> > Subject: Need an opinion, on whether to change package or not
> >>> >
> >>> >> Consider this an official request for a vote.
> >>> >>
> >>> >> +1 indicates you think we should change the following in the source
> >>> code, as
> >>> >> soon as is practical:
> >>> >>
> >>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
> >>> >> All classes LCF.java and LCFException.java should change to ACF.java
> >>> and
> >>> >> ACFException.java
> >>> >>
> >>> >> Bear in mind that users of ACF/LCF who currently have existing
> database
> >>> >> instances will need to reinitialize those instances if we do this
> >>> change.
> >>> >> This is because the class names of connectors are stored in the
> >>> database
> >>> >> when the connector is registered.
> >>> >>
> >>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
> >>>  But I
> >>> >> will of course abide by the consensus.)
> >>> >>
> >>> >> Vote will be considered closed by Wednesday evening, so vote early
> (and
> >>> >> often. ;-))
> >>> >> Karl
> >>>
> >>
> >>
> >>
> >> --
> >> Jettro Coenradie
> >> http://www.gridshore.nl
> >>
> >
> >
> >
> > --
> > Jettro Coenradie
> > http://www.gridshore.nl
> >
>



--
Jettro Coenradie
http://www.gridshore.nl

Re: Need an opinion, on whether to change package or not

[Jettro Coenradie]

I can understand that it is harder to do. Therefore it is better notto do it
right now. I do not agree with you that it is easier to move files from one
package to another. The fact that these classes have different impact should
make you think before moving the classes. I would like to discuss on some of
these design/code issues more as well. What is the best way to do this? Ask
a question per topic to share opinions?

thanks Jettro

On Mon, Aug 23, 2010 at 10:54 AM,  wrote:

> Unfortunately that is way harder to do using the python scripts I have
> developed for this purpose.  Also, the reason the LCF root class appears in
> different packages has to do with the relative ease that grants to moving
> classes between the various acf jars.  So I'd consider this proposed change
> to be controversial, and I don't think we should layer it in without
> separate consideration.
>
> Karl
>
> 
> From: ext Simon Willnauer [simon.willna...@googlemail.com]
> Sent: Monday, August 23, 2010 4:40 AM
> To: connectors-dev@incubator.apache.org
> Subject: Re: Need an opinion, on whether to change package or not
>
> On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie
>  wrote:
> > If we are changing stuff can we also use more descriptive names. Not Use
> LCF
> > 4 to 5 times in a different Package. Use something like ACFAgent and
> > ACFCrawler
> +1  for that too!
>
> simon
> >
> > On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
> > jettro.coenra...@gridshore.nl> wrote:
> >
> >> +1 for a complete change
> >>
> >>
> >> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller  >wrote:
> >>
> >>> +1 to renaming the package - nows the time.
> >>>
> >>> - Mark
> >>>
> >>> http://www.lucidimagination.com (mobile)
> >>>
> >>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
> >>> jack.krupan...@lucidimagination.com> wrote:
> >>>
> >>> > +1
> >>> >
> >>> > -- Jack Krupansky
> >>> >
> >>> > --
> >>> > From: "Karl Wright" 
> >>> > Sent: Sunday, August 22, 2010 1:49 PM
> >>> > To: "connectors-dev" 
> >>> > Subject: Need an opinion, on whether to change package or not
> >>> >
> >>> >> Consider this an official request for a vote.
> >>> >>
> >>> >> +1 indicates you think we should change the following in the source
> >>> code, as
> >>> >> soon as is practical:
> >>> >>
> >>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
> >>> >> All classes LCF.java and LCFException.java should change to ACF.java
> >>> and
> >>> >> ACFException.java
> >>> >>
> >>> >> Bear in mind that users of ACF/LCF who currently have existing
> database
> >>> >> instances will need to reinitialize those instances if we do this
> >>> change.
> >>> >> This is because the class names of connectors are stored in the
> >>> database
> >>> >> when the connector is registered.
> >>> >>
> >>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
> >>>  But I
> >>> >> will of course abide by the consensus.)
> >>> >>
> >>> >> Vote will be considered closed by Wednesday evening, so vote early
> (and
> >>> >> often. ;-))
> >>> >> Karl
> >>>
> >>
> >>
> >>
> >> --
> >> Jettro Coenradie
> >> http://www.gridshore.nl
> >>
> >
> >
> >
> > --
> > Jettro Coenradie
> > http://www.gridshore.nl
> >
>



-- 
Jettro Coenradie
http://www.gridshore.nl

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Attachment: change_commands_with_system_err_println.patch

added system err println lines back to the main methods

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch, 
> change_commands_with_system_err_println.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: Need an opinion, on whether to change package or not

[karl.wright]

Unfortunately that is way harder to do using the python scripts I have 
developed for this purpose.  Also, the reason the LCF root class appears in 
different packages has to do with the relative ease that grants to moving 
classes between the various acf jars.  So I'd consider this proposed change to 
be controversial, and I don't think we should layer it in without separate 
consideration.

Karl


From: ext Simon Willnauer [simon.willna...@googlemail.com]
Sent: Monday, August 23, 2010 4:40 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Need an opinion, on whether to change package or not

On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie
 wrote:
> If we are changing stuff can we also use more descriptive names. Not Use LCF
> 4 to 5 times in a different Package. Use something like ACFAgent and
> ACFCrawler
+1  for that too!

simon
>
> On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
> jettro.coenra...@gridshore.nl> wrote:
>
>> +1 for a complete change
>>
>>
>> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller wrote:
>>
>>> +1 to renaming the package - nows the time.
>>>
>>> - Mark
>>>
>>> http://www.lucidimagination.com (mobile)
>>>
>>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
>>> jack.krupan...@lucidimagination.com> wrote:
>>>
>>> > +1
>>> >
>>> > -- Jack Krupansky
>>> >
>>> > --
>>> > From: "Karl Wright" 
>>> > Sent: Sunday, August 22, 2010 1:49 PM
>>> > To: "connectors-dev" 
>>> > Subject: Need an opinion, on whether to change package or not
>>> >
>>> >> Consider this an official request for a vote.
>>> >>
>>> >> +1 indicates you think we should change the following in the source
>>> code, as
>>> >> soon as is practical:
>>> >>
>>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
>>> >> All classes LCF.java and LCFException.java should change to ACF.java
>>> and
>>> >> ACFException.java
>>> >>
>>> >> Bear in mind that users of ACF/LCF who currently have existing database
>>> >> instances will need to reinitialize those instances if we do this
>>> change.
>>> >> This is because the class names of connectors are stored in the
>>> database
>>> >> when the connector is registered.
>>> >>
>>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
>>>  But I
>>> >> will of course abide by the consensus.)
>>> >>
>>> >> Vote will be considered closed by Wednesday evening, so vote early (and
>>> >> often. ;-))
>>> >> Karl
>>>
>>
>>
>>
>> --
>> Jettro Coenradie
>> http://www.gridshore.nl
>>
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>

[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901316#action_12901316
 ] 

Jettro Coenradie commented on CONNECTORS-91:


Hmm, I think the logging option is better, if people provide the right 
configuration you have what you need and even more. But I understand what you 
mean with the main method implementation.

I'll add it back and provide a new patch.

I also tried the sample with the new classes and it all seems to work. Is that 
good enough?

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901312#action_12901312
 ] 

Karl Wright commented on CONNECTORS-91:
---

Another thing I had not noticed before is that this patch removes all stderr 
success confirmation messages for those folks who use the commands, and 
replaces them with log output.  The log output is perfectly fine, but removing 
the feedback that the command was successful is, I think, not great.  If the 
log were going to stderr typically that would be OK, but it typically is not, 
so I think you are going to want to do both.  You would, obviously, want to do 
the stderr output within the main() method.

Would it be possible to fix that up before I commit this?


> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Need an opinion, on whether to change package or not

[Simon Willnauer]

On Mon, Aug 23, 2010 at 10:35 AM, Jettro Coenradie
 wrote:
> If we are changing stuff can we also use more descriptive names. Not Use LCF
> 4 to 5 times in a different Package. Use something like ACFAgent and
> ACFCrawler
+1  for that too!

simon
>
> On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
> jettro.coenra...@gridshore.nl> wrote:
>
>> +1 for a complete change
>>
>>
>> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller wrote:
>>
>>> +1 to renaming the package - nows the time.
>>>
>>> - Mark
>>>
>>> http://www.lucidimagination.com (mobile)
>>>
>>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
>>> jack.krupan...@lucidimagination.com> wrote:
>>>
>>> > +1
>>> >
>>> > -- Jack Krupansky
>>> >
>>> > --
>>> > From: "Karl Wright" 
>>> > Sent: Sunday, August 22, 2010 1:49 PM
>>> > To: "connectors-dev" 
>>> > Subject: Need an opinion, on whether to change package or not
>>> >
>>> >> Consider this an official request for a vote.
>>> >>
>>> >> +1 indicates you think we should change the following in the source
>>> code, as
>>> >> soon as is practical:
>>> >>
>>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
>>> >> All classes LCF.java and LCFException.java should change to ACF.java
>>> and
>>> >> ACFException.java
>>> >>
>>> >> Bear in mind that users of ACF/LCF who currently have existing database
>>> >> instances will need to reinitialize those instances if we do this
>>> change.
>>> >> This is because the class names of connectors are stored in the
>>> database
>>> >> when the connector is registered.
>>> >>
>>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
>>>  But I
>>> >> will of course abide by the consensus.)
>>> >>
>>> >> Vote will be considered closed by Wednesday evening, so vote early (and
>>> >> often. ;-))
>>> >> Karl
>>>
>>
>>
>>
>> --
>> Jettro Coenradie
>> http://www.gridshore.nl
>>
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>

Re: Need an opinion, on whether to change package or not

[Jettro Coenradie]

If we are changing stuff can we also use more descriptive names. Not Use LCF
4 to 5 times in a different Package. Use something like ACFAgent and
ACFCrawler

On Mon, Aug 23, 2010 at 10:33 AM, Jettro Coenradie <
jettro.coenra...@gridshore.nl> wrote:

> +1 for a complete change
>
>
> On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller wrote:
>
>> +1 to renaming the package - nows the time.
>>
>> - Mark
>>
>> http://www.lucidimagination.com (mobile)
>>
>> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
>> jack.krupan...@lucidimagination.com> wrote:
>>
>> > +1
>> >
>> > -- Jack Krupansky
>> >
>> > --
>> > From: "Karl Wright" 
>> > Sent: Sunday, August 22, 2010 1:49 PM
>> > To: "connectors-dev" 
>> > Subject: Need an opinion, on whether to change package or not
>> >
>> >> Consider this an official request for a vote.
>> >>
>> >> +1 indicates you think we should change the following in the source
>> code, as
>> >> soon as is practical:
>> >>
>> >> org.apache.lcf.xxx -> org.apache.acf.xxx
>> >> All classes LCF.java and LCFException.java should change to ACF.java
>> and
>> >> ACFException.java
>> >>
>> >> Bear in mind that users of ACF/LCF who currently have existing database
>> >> instances will need to reinitialize those instances if we do this
>> change.
>> >> This is because the class names of connectors are stored in the
>> database
>> >> when the connector is registered.
>> >>
>> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
>>  But I
>> >> will of course abide by the consensus.)
>> >>
>> >> Vote will be considered closed by Wednesday evening, so vote early (and
>> >> often. ;-))
>> >> Karl
>>
>
>
>
> --
> Jettro Coenradie
> http://www.gridshore.nl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

Re: Need an opinion, on whether to change package or not

[Jettro Coenradie]

+1 for a complete change

On Mon, Aug 23, 2010 at 6:34 AM, Mark Miller  wrote:

> +1 to renaming the package - nows the time.
>
> - Mark
>
> http://www.lucidimagination.com (mobile)
>
> On Aug 22, 2010, at 8:01 PM, "Jack Krupansky" <
> jack.krupan...@lucidimagination.com> wrote:
>
> > +1
> >
> > -- Jack Krupansky
> >
> > --
> > From: "Karl Wright" 
> > Sent: Sunday, August 22, 2010 1:49 PM
> > To: "connectors-dev" 
> > Subject: Need an opinion, on whether to change package or not
> >
> >> Consider this an official request for a vote.
> >>
> >> +1 indicates you think we should change the following in the source
> code, as
> >> soon as is practical:
> >>
> >> org.apache.lcf.xxx -> org.apache.acf.xxx
> >> All classes LCF.java and LCFException.java should change to ACF.java and
> >> ACFException.java
> >>
> >> Bear in mind that users of ACF/LCF who currently have existing database
> >> instances will need to reinitialize those instances if we do this
> change.
> >> This is because the class names of connectors are stored in the database
> >> when the connector is registered.
> >>
> >> (FWIW, my vote on this is -1.  It doesn't seem worth the disruption.
>  But I
> >> will of course abide by the consensus.)
> >>
> >> Vote will be considered closed by Wednesday evening, so vote early (and
> >> often. ;-))
> >> Karl
>



-- 
Jettro Coenradie
http://www.gridshore.nl

[jira] Commented: (CONNECTORS-91) Making the initialization commands more useable

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901309#action_12901309
 ] 

Karl Wright commented on CONNECTORS-91:
---

This patch file worked properly.
Since the automated tests do not exercise the commands, it would be good to set 
up a database instance from scratch using the changed code.  If you have 
already done this, please let me know and I will go ahead and commit the 
changes.


> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Comment: was deleted

(was: sorry, pushed the wrong button I guess)

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Comment: was deleted

(was: Some strange things are happening, not sure what went wrong. I did do an 
svn up, I am sure of that. Nevertheless, I think I have it working now. You 
might need to change the depth of which to apply the patch.

I recreated the patch with intellij and it uses one folder of my own. The 
following command strips of this folder

patch -p1 -i ~/change_commands.patch

I tried it on a clean checkout of the project locally and it seems to work

Hope it works now, sorry I did not try it myself before)

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Attachment: (was: commandsPatch.patch)

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Attachment: (was: changesToCommandClasses.patch)

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Attachment: change_commands.patch

Some strange things are happening, not sure what went wrong. I did do an svn 
up, I am sure of that. Nevertheless, I think I have it working now. You might 
need to change the depth of which to apply the patch.

I recreated the patch with intellij and it uses one folder of my own. The 
following command strips of this folder

patch -p1 -i ~/change_commands.patch

I tried it on a clean checkout of the project locally and it seems to work

Hope it works now, sorry I did not try it myself before

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: change_commands.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Status: Patch Available  (was: Open)

Some strange things are happening, not sure what went wrong. I did do an svn 
up, I am sure of that. Nevertheless, I think I have it working now. You might 
need to change the depth of which to apply the patch.

I recreated the patch with intellij and it uses one folder of my own. The 
following command strips of this folder

patch -p1 -i ~/change_commands.patch

I tried it on a clean checkout of the project locally and it seems to work

Hope it works now, sorry I did not try it myself before

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: changesToCommandClasses.patch, commandsPatch.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CONNECTORS-91) Making the initialization commands more useable

[Jettro Coenradie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CONNECTORS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jettro Coenradie updated CONNECTORS-91:
---

Status: Open  (was: Patch Available)

sorry, pushed the wrong button I guess

> Making the initialization commands more useable
> ---
>
> Key: CONNECTORS-91
> URL: https://issues.apache.org/jira/browse/CONNECTORS-91
> Project: Apache Connectors Framework
>  Issue Type: Improvement
>  Components: Framework core
>Reporter: Jettro Coenradie
> Fix For: LCF Release 0.5
>
> Attachments: changesToCommandClasses.patch, commandsPatch.patch
>
>
> At the moment LCF comes with some classes that can be used to run command 
> line to interact with the system. Examples are DBCreate, DBDrop and 
> LockClean. I wanted to create a class that rebuilds my complete environment. 
> So dropping a database, creating a database, cleaning the synch folder, 
> registering agents, etc. Due to the structure of the classes with all the 
> logic in the main method, I could not easily reuse these classes. In the 
> patch I submit with issue I have refactored the current solution in a better 
> reuseable solution that can still be called command line.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.