[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: EPL vs Apache [Re: [pde-build-dev] Can I get an update on the maven jar?]
|
I think it would ultimately be best to refactor pde build as several pieces could be used for other build tools like, ivy. I have spent part of the day trading emails with one of the maven PMC members and he talks of preparing a proposal for an eclipse (sub-)project. Thus the code may eventually end up at eclipse anyway. There is no immediate need to upset the status quo, but I wanted to get the questions asked.
Wb
On 9/6/06, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
Hi Wendell,
This is a question for the lawyers.
As I understand it, our code needs to stay under the EPL .
If we perhaps consider splitting the
project into 2 pieces: EPL classpath code and Apache mojo code, I see the
following options for hosting this project:
1) Apache hosts EPL code and everything
lives there.
2) Apache hosts the mojo code and just
has EPL binaries. EPL code is hosted somewhere else:
a)
Sourceforge
b)
Eclipse.
3) Everything is hosted somewhere else.
Sourceforge, Eclipse. (A pde.build incubator?).
In light of the fact that we don't currently
have the resources to do a lot of maintenance on this going forward,
I think 2a is the best choice if 1 is not a valid option. For 2b
an option is to consider refactoring pde.build itself so that a jar with
the necessary bits could be built directly from the main pde.build source.
-Andrew
Could you use the latest code in the
http://www.binyan.org/repos/pde/trunk/maven-pde-plugin
project. This is the same code with a few functions made static for
reuse, etc.
Also I have been asked about putting theis code with the other maven mojo
projects. I don't have a preference for whether eclipse or apache
hosts the project, so if you're ok, can the code you provided to me be
(re)licensed under the Apache Software License 2.0?
Wb
On 9/5/06, Andrew Niefer <aniefer@xxxxxxxxxx
>
wrote:
Hi Wendell,
We do have code in pde.build that gets a list of reasons like you want.
I'll look at porting it over.
Are you using the MavenGenerator as is? If it's more than just an
example I'm sure it could have a better API and a more convenient way of
outputing the classpath instead of just writing to system.out.
I'll check about a place to put the code. The org.eclipse.pde.maven
code currently just lives on my computer.
-Andrew
The code in the MavenGenerator had the following line in the generate(...)
method
bundle = state.getResolvedBundle(bundleId);
What would be very user friendly is if there was a method to get a list
of reasons why a bundle was not resolved ( i.e. missing required plugin
org.foo version 1.2.3, unsatisfied package import com.bar, etc.)
I currently have the maven-pde-plugin building jar plugins, features and
update sites and I would like to add this capability to report what's missing
before I make the next release.
On a side note, I would like to move this code to eclipse.org
proper preferably pde. What would be required to
get vetted in making that happen. I think it would greatly help the
visibility as well as get more use cases exposed and supported.
Wb_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev